Ir al contenido
SV Dev
← Volver al blog

Seguridad · Agentes de IA · Fintech · Arquitectura

Agente de IA y contraseña bancaria: quién paga la pérdida

¿Tu agente de IA pide la contraseña del banco? La Regulation E borra el tope de US$ 50 y la cuenta la paga tu cliente. Se decide en la semana uno.

Jeferson Guardezi
Digital Services Terms of Use de U.S. Bank: la actividad realizada con tus credenciales de acceso se presume autorizada por ti, y revocar el acceso compartido con un tercero exige contactar al banco para establecer nuevas credenciales.

En algún punto de tu onboarding hay un campo que le pide al usuario la contraseña de un sistema que no es tuyo. Y funciona. Se demuestra muy bien, y es la razón por la que tu agente hace cosas en lugar de hablar de ellas.

Bank of America pasó la semana enviando correos a sus clientes para pedirles que no lo completen. El aviso se titula "Protecting your finances in the AI World", y la línea que importa no es la advertencia sino la siguiente: "If you do share your credentials, keep in mind that you're responsible for activity resulting from that access" — eres responsable de la actividad que resulte de ese acceso.

Eso no es un banco siendo severo. Es un banco describiendo una exclusión de definición en la ley federal estadounidense. Bajo la Regulation E una contraseña es un "medio de acceso", y una transferencia iniciada por quien recibió ese medio de acceso de manos del consumidor no es una "transferencia electrónica no autorizada". El tope de US$ 50 no se debilita: desaparece la categoría en la que vive.

El correo de Bank of America, "Protecting your finances in the AI World": nunca entregues tu usuario y contraseña a una herramienta o agente de IA, y eres responsable de la actividad que resulte de ese acceso.

El correo se publicó el 27 de octubre y un vocero del banco lo confirmó a TechCrunch. Así que ese campo de tu registro no es una integración. Es una transferencia de responsabilidad, y transfiere hacia tu propio cliente.

Lo que esto te cuesta, en cuatro lugares

Quién absorbe la pérdida. Con un token delegado, una transferencia disputada sigue siendo una disputa: proceso del banco, reglas de reembolso del banco. Con una contraseña entregada, la norma le pasa la cuenta a quien la escribió, y tu cola de soporte hereda la conversación. Explicar tu arquitectura no la gana.

Si tu acceso sobrevive el trimestre. El Online Banking Service Agreement de Bank of America ya prohíbe compartir credenciales con terceros, salvo tutela legal y poder notarial, y reserva al banco suspender o terminar el servicio "in our sole discretion". Una integración basada en credenciales incumple el contrato desde el día uno, no después del incidente. Jamie Dimon dijo a los analistas en la llamada de resultados de JPMorgan del 13 de octubre que el banco no dejará entrar agentes externos; un vocero de Chase dijo a CBS News que los clientes no deben dar su usuario y contraseña a nadie.

El Online Banking Service Agreement de Bank of America: compartir credenciales con terceros está prohibido salvo tutela o poder notarial, y el banco puede suspender o terminar a su exclusivo criterio.

Si el offboarding es un botón o una llamada. Revocar un token es un clic. Revocar una contraseña significa que tu usuario llame a su banco, espere y rote una credencial que rompe todas sus demás integraciones. Ese es tu flujo de churn, y no controlas nada de él.

Si puedes venderle a un comprador regulado. Toda evaluación de proveedor seria pregunta cómo te autenticas en sistemas de terceros. "Guardamos la contraseña bancaria del cliente" termina la evaluación — ya vimos esa respuesta matar un negocio en etapa final.

Y hay un punto que pega distinto en nuestra región: si atiendes clientes en Estados Unidos, la norma estadounidense decide quién paga, aunque tu equipo esté en Bogotá o Ciudad de México. En Europa la PSD2 ya cerró el camino del scraping de credenciales y obligó al acceso delegado; en México y Chile las leyes fintech empujan igual. El diseño que los bancos exigen no es una rareza local: es la dirección de toda la regulación.

Rehacer la autenticación tras el lanzamiento no es refactorizar. Es volver a dar de alta a toda tu base.

Qué está documentado y qué no

Esta semana circulan dos tipos de afirmación y merecen pesos distintos.

Documentado, en fuente primaria: el correo de Bank of America, las definiciones de la Regulation E y los términos de uso citados aquí. Textos con URL, que puedes verificar tú mismo.

Autorreportado, y mucho más delgado: la afirmación de que los grandes bancos estadounidenses están detectando hoy actividad no autorizada de agentes de IA dentro de cuentas de clientes viene de una nota de Axios basada en gran parte en fuentes bancarias no identificadas. Ningún banco publicó datos, no hay conteo de incidentes y no se ha atribuido ninguna pérdida a esto; CBS News retransmitió el hallazgo en una entrevista con la reportera de Axios, sin confirmarlo de forma independiente. Los reportes de que Bank of America restringió a los agentes a solo lectura y de que Morgan Stanley los bloqueó del todo vienen de esa misma fuente, y la afirmación de Morgan Stanley de no haber observado actividad no autorizada es la propia firma hablando de sí misma. La posición de David Sacks, zar de IA de la Casa Blanca, de que la mayor parte de ese tráfico está autorizado por el usuario y no es un ataque, es su declaración pública, contradicha por la lectura que los bancos hacen de sus contratos.

El argumento de arquitectura no depende de la nota. Se sostiene en la norma y en los contratos, y esos no se mueven.

La cláusula que borra el tope

El 12 CFR 1005.6(b) limita la pérdida del consumidor en una transferencia no autorizada a US$ 50, o US$ 500 sin aviso oportuno: la protección que todos suponen que está ahí. Y el 1005.2(m)(1) dice que "transferencia electrónica de fondos no autorizada" "no incluye una transferencia ... iniciada por una persona a quien el consumidor le entregó el medio de acceso a su cuenta", mientras el 1005.2(a)(1) define medio de acceso como "una tarjeta, un código u otro medio de acceso".

Regulation E, 12 CFR 1005.2(m): una "transferencia electrónica no autorizada" no incluye la iniciada por alguien a quien el consumidor entregó el medio de acceso.

Una contraseña es un código. Ese es todo el argumento. Entrega la credencial y la transferencia que haga tu agente — o quien lo comprometa — no es no autorizada. Es autorizada, por el cliente, a través de ti.

No puedes despedir al agente

Los Digital Services Terms of Use vigentes de U.S. Bank son más directos que cualquier cobertura. La actividad realizada con tus Login Credentials "will be presumed to be authorized by you unless you tell us otherwise", el banco "no es responsable de gestionar la autoridad de tus relaciones con terceros", y para detener el acceso "you must contact us to block access to Digital Services until new Login Credentials are established".

Digital Services Terms of Use de U.S. Bank: la actividad con tus credenciales se presume autorizada, y revocar el acceso compartido exige contactar al banco para establecer nuevas credenciales.

Léelo como ingeniero. No hay endpoint de revocación porque no hay concesión que revocar: el agente no es un delegado, es el cliente. Revocar es una rotación de credencial hecha por un humano en una llamada, y es indiscriminada: también mata la app de presupuesto, el acceso del contador y la integración de cada competidor. Un agente que no puedes apagar es la misma falla de plano de control que un agente que silencia sus propias alertas: el interruptor está donde no alcanzas.

El camino autorizado, en palabras del banco

El mismo contrato nombra la arquitectura que el banco acepta: "you login directly with us and provide sharing instructions ... You can manage your data sharing instructions, and revoke your authorization, using Digital Services". Entregar credenciales, en cambio, autoriza al servicio a acceder a la cuenta "pudiendo incluir la capacidad de iniciar transferencias".

Los dos caminos en los términos de U.S. Bank: dar instrucciones de compartición revocables en el banco, o entregar credenciales y autorizar transferencias.

Delegado, con alcance, revocable por el cliente: la forma OAuth, descrita por un banco que no te dará otra opción. Lo incómodo es que hoy ningún mandato federal obliga a abrirlo: la Part 1033 sigue en el CFR, pero una consulta al Federal Register esta semana no encontró regla de Personal Financial Data Rights reeditada. El camino tokenizado es concesión del banco, lo que convierte "ser fácil de autorizar" en posición comercial, no en checkbox de cumplimiento.

La decisión, en la semana uno

Si todavía no lanzaste, esto sale barato. Tres reglas:

  1. Nunca recibas una credencial de terceros en tu sistema. Ni cifrada en reposo, ni "solo en memoria", ni vía navegador headless. La posesión es el evento de responsabilidad, sin importar tu higiene.
  2. Usa el camino delegado del proveedor donde exista — OAuth, un agregador autorizado por el banco, APIs de open banking. Lectura con alcance donde solo lees; escritura explícita y aparte donde mueves dinero.
  3. Haz de la revocación una función tuya. El usuario debe poder cortar tu acceso desde dentro de tu producto, y tú debes poder probar cuándo se cortó.

Si ya lanzaste con captura de credenciales, la migración es un problema de producto, no de autenticación: cada usuario actual tiene que volver a consentir por un flujo que aún no existe, mientras el camino viejo sigue funcionando. Presupuéstalo como feature, ponle dueño y fecha para apagar el camino viejo. El costo crece con tu curva de registros, la única curva que querías que creciera.

Esa es la mayor parte del trabajo para el que nos llaman: una decisión de autenticación de la semana uno que aparece en el mes nueve como el bloqueo de un contrato enterprise.

Puntos clave

  • Una contraseña es un "medio de acceso" bajo 12 CFR 1005.2(a)(1), así que entregarla saca la transferencia de la definición de "no autorizada" del 1005.2(m)(1) y de los topes del 1005.6(b).
  • El correo repite una cláusula que ya existía: el contrato de Bank of America ya prohibía compartir credenciales fuera de tutela y poder notarial, y reserva la terminación a su exclusivo criterio.
  • La revocación no pasa por tu producto. U.S. Bank exige una llamada y una rotación de credencial que rompe las demás integraciones del usuario.
  • Que los bancos estén detectando agentes clandestinos ahora es de fuente única y no identificada. Los problemas de contrato y de norma no necesitan esa nota.
  • Captura de credenciales frente a autorización delegada es una decisión de semana uno que fija cuatro resultados: quién absorbe la pérdida, continuidad de acceso, costo de salida y si un comprador regulado puede decir sí.
Trabajamos con founders en cualquier lugar del mundo que tienen un producto funcional construido con IA — y el buen juicio de querer ojos sénior sobre él antes de que lleguen los usuarios reales.

Recibir revisión

¿Listo para lanzar con confianza?

30 minutos con un ingeniero sénior. Te decimos exactamente qué separa tu producto de la producción.

Obtén una revisión de tu producto

30 minutos, sin pitch, sin presión. Si tu producto ya está listo para lanzar como está, también te lo diremos.