Cada vez más empresas ajenas al sistema financiero, como marketplaces, aplicaciones de movilidad, cadenas de comercio o compañías de software, evalúan incorporar a su producto una cuenta digital en la que sus usuarios puedan cobrar, pagar y mantener saldo sin salir de la aplicación. En Argentina, la vía más habitual para hacerlo sin convertirse en una entidad regulada consiste en apoyarse en un proveedor de servicios de pago que ofrece cuentas de pago y aporta la infraestructura, mientras la empresa pone la marca, la interfaz y la relación comercial con sus clientes.
Ese esquema, que en el ecosistema se conoce como marca blanca, embedded finance o banking as a service, funcionó durante años sin un encuadre específico en la normativa del Banco Central. La Comunicación “A” 8432, emitida el 30 de abril de 2026, lo reguló de manera expresa bajo la figura del “PSPCP como Servicio”, con consecuencias que alcanzan al proveedor regulado y también a la empresa que integra la billetera, aunque esta última no se inscriba como proveedor de servicios de pago.
Qué es un proveedor de servicios de pago como servicio
El texto ordenado del BCRA sobre la materia distingue, entre otras categorías, a los proveedores que ofrecen cuentas de pago (PSPCP), cuyo marco general repasamos en la nota sobre regulación fintech en Argentina. La Comunicación “A” 8432 incorporó el punto 1.4.1.1, que define al PSPCP como Servicio como aquel que ofrece cuentas de pago, y eventualmente el servicio de billetera digital interoperable, a clientes de un tercero tomador del servicio, que usan esas cuentas mediante una interfaz provista por ese tercero e integrada tecnológicamente al PSPCP.
La definición recoge una operatoria que el mercado ya conocía. El tomador diseña la aplicación, capta a los usuarios y gestiona la experiencia, mientras que el proveedor de servicios de pago es el titular de la relación regulatoria y el que responde ante el BCRA por el funcionamiento de las cuentas. Lo novedoso es que, aunque las obligaciones recaen formalmente sobre el PSPCP, el regulador las proyecta sobre el tomador mediante un mecanismo de habilitación previa, exigencias que el proveedor debe trasladarle por contrato y una obligación directa sobre el diseño de su interfaz.
Cómo crear una billetera virtual en Argentina
Una empresa que quiere ofrecer cuentas de pago con su marca tiene, en términos generales, dos caminos. El primero es inscribirse ella misma como PSPCP en el registro del BCRA, con oficial de cumplimiento ante la UIF cuando el PSP es sujeto obligado, bancos patrocinantes, control de antecedentes de accionistas y autoridades, y los regímenes informativos, de protección de usuarios, de seguridad de la información y de prevención del fraude. Una vez obtenida la inscripción, el PSP cuenta con un plazo máximo de doce meses para iniciar operaciones, que la propia Comunicación “A” 8432 extendió desde los seis meses previstos anteriormente.
El segundo camino consiste en operar como tomador de un proveedor de servicios de pago que ofrece cuentas como servicio. La empresa no se inscribe por sí misma como PSP, pero queda habilitada en el registro a través de la nómina que el PSPCP debe presentar ante el BCRA, y el proveedor no puede prestarle el servicio hasta que el Banco Central notifique esa habilitación. Para compañías cuyo negocio principal no es financiero, suele ser el esquema más razonable en tiempos y costos.
Qué obligaciones recaen sobre la empresa que integra la billetera
Requisitos societarios y habilitación previa
El punto 3 de la Comunicación “A” 8432 extiende a los tomadores las exclusiones que rigen para los PSP, de modo que no puede serlo una sociedad que no esté regularmente constituida en el país o que, siendo extranjera, no haya cumplido la Ley General de Sociedades 19.550 para actuar habitualmente en la Argentina. Las startups que operan desde una sociedad del exterior tienen que revisar su estructura societaria internacional antes de firmar. El PSPCP debe informar además, respecto de cada tomador, a los titulares de al menos el 10% del capital o de los votos, a quienes ejerzan el control final y a los integrantes de sus órganos de administración y fiscalización, con declaraciones juradas suscriptas con firma digital. En los hechos, la composición accionaria del tomador pasa a formar parte del legajo que el proveedor de servicios de pago presenta al regulador.
Onboarding, prevención del fraude y seguridad de la información
Entre las disposiciones particulares que la comunicación incorporó como sección 4.5 del texto ordenado, el punto 4.5.4 exige que las interfaces, procesos y sistemas del tomador se ajusten a la normativa del BCRA sobre conocimiento del cliente, onboarding digital, prevención del lavado de activos y del fraude, seguridad de la información y continuidad operativa, y pone en cabeza del PSPCP fijar esas exigencias por contrato y verificar su implementación. Como la Comunicación “A” 8398 incorporó a los PSP al régimen de requisitos mínimos de tecnología y seguridad de la información y la Comunicación “A” 8471 sumó para los PSPCP un marco de gestión del riesgo de fraude, que se implementa por etapas hasta su vigencia plena el 1 de septiembre de 2027 y se complementa con el puntaje de riesgo de fraude de uso obligatorio de la Comunicación “A” 8473, también de aplicación progresiva, el tomador termina heredando controles propios del sistema financiero, que en la práctica se traducen en auditorías, plazos cortos de notificación de incidentes y exigencias sobre sus subcontratistas, como vimos en la nota sobre ciberseguridad y contratos con proveedores.
Identificación del proveedor en la pantalla de saldo
El punto 4.5.3, cuyo texto fue sustituido por la Comunicación “A” 8497 con vigencia desde el 1 de noviembre de 2026, impone una obligación concreta de diseño. La interfaz del tomador debe exhibir, en la vista que muestra el saldo y de manera clara y legible, la denominación comercial del PSP que provee la cuenta, junto con la información que exigen las normas aplicables, entre ellas las de protección de los usuarios de servicios financieros, sin perjuicio de la responsabilidad del PSPCP por su cumplimiento. La misma comunicación agregó deberes de información para las billeteras que ofrecen inversión en fondos comunes de dinero, que deben exhibir la variación de la cuotaparte de los últimos siete días expresada como tasa nominal anual, junto con los datos que identifican al fondo. Son exigencias que conviene incorporar al diseño desde la primera versión de la aplicación.
Quién responde frente al usuario cuando la billetera lleva la marca del tomador
Según el punto 4.5.1, en lo que al uso de las cuentas concierne, los clientes del tercero son clientes del PSPCP, y el punto 4.5.2 agrega que esa modalidad no libera al proveedor de cumplir toda la reglamentación aplicable. Leídas en forma aislada, estas reglas sugieren que el tomador queda al margen de los reclamos vinculados con la cuenta, una lectura que pierde de vista el derecho del consumidor. El artículo 40 de la Ley 24.240 de Defensa del Consumidor establece la responsabilidad solidaria de toda la cadena, incluido quien haya puesto su marca en la cosa o servicio, cuando el daño resulta del vicio o riesgo de la prestación. En el modelo de marca blanca, el tomador es precisamente quien pone su marca frente a un usuario que muchas veces ni siquiera percibe que detrás de la aplicación hay un proveedor de servicios de pago. La aplicación de ese artículo a servicios financieros tiene matices, pero la posición del tomador lo expone a ser demandado en forma solidaria.
A eso se suma la conexidad contractual prevista en los artículos 1073 a 1075 del Código Civil y Comercial, que se configura cuando varios contratos autónomos persiguen una finalidad económica común y debe acreditarse según las circunstancias de cada caso. Aunque no constituye por sí sola un régimen de responsabilidad solidaria, puede hacer que el vínculo del usuario con el PSPCP, su vínculo con la plataforma y el contrato entre ambas empresas sean difíciles de separar en un litigio. La distribución de responsabilidades tiene que resolverse en el contrato entre tomador y proveedor, con indemnidades y mecanismos de repetición claros, con la misma lógica que desarrollamos sobre la dependencia de APIs de terceros, agravada aquí porque el servicio del que se depende está regulado.
La misma dualidad aparece en materia de datos personales, porque el tomador recolecta en su interfaz información que en buena medida sirve para cumplir obligaciones de conocimiento del cliente del PSPCP. Frente a la Ley 25.326, puede ser responsable respecto de los datos que usa para su propio negocio y, a la vez, prestador de servicios de tratamiento en los términos del artículo 25 respecto de los que procesa por cuenta del proveedor, una distinción que conviene resolver en el contrato y en la política de privacidad, tal como analizamos al tratar quién es responsable del tratamiento en plataformas.
Qué revisar en el contrato con el proveedor de servicios de pago
A partir de la Comunicación “A” 8432 y de las normas conexas, el contrato entre el tomador y el PSPCP debería abordar, como mínimo, los siguientes aspectos.
- La condición de que la operatoria comience recién con la habilitación notificada por el BCRA, y las consecuencias de una demora o de una denegación.
- La distribución detallada de los controles de onboarding, prevención del fraude, prevención del lavado de activos y seguridad de la información, con los mecanismos de verificación del proveedor.
- Las facultades de auditoría y verificación del PSPCP, que la norma le exige ejercer en el punto 4.5.4 sin detallar su alcance, y la obligación de mantener el contrato a disposición de la Superintendencia de Entidades Financieras y Cambiarias que impone el punto 4.5.5.
- Los plazos de notificación de incidentes y fraudes, la comunicación a usuarios y autoridades y la asignación de pérdidas.
- Los roles de cada parte bajo la Ley 25.326, las finalidades autorizadas y las indemnidades frente a reclamos y sanciones según el origen del incumplimiento.
- La migración de cuentas y saldos si el proveedor pierde su registración, sanción que el punto 4.5.6 prevé ante el incumplimiento de estas disposiciones, o si cualquiera de las partes termina la relación.
Cuestiones que la norma deja abiertas
La Comunicación “A” 8432 no precisa los efectos de una revocación de la habilitación del tomador, que no lo convierte en proveedor de servicios de pago inscripto pero lo somete a un control previo del regulador, ni fija estándares para el deber de verificación del PSPCP sobre sus controles. Además, como los PSPCP que ya prestaban el servicio tuvieron noventa días para adecuarse, conviene revisar si los contratos firmados bajo el esquema anterior reflejan hoy las exigencias del punto 4.5.4.
Preguntas frecuentes sobre el proveedor de servicios de pago como servicio
¿Qué es un PSPCP como Servicio?
Es un proveedor de servicios de pago que ofrece cuentas de pago, y eventualmente billetera digital interoperable, a los clientes de otra empresa, que acceden a esas cuentas desde la interfaz de esa empresa. La figura fue incorporada por la Comunicación “A” 8432.
¿Hay que inscribirse en el BCRA para ofrecer una billetera virtual con marca propia?
Si la empresa opera como tomadora de un PSPCP como Servicio, no necesita inscribirse por sí misma como PSP, pero debe quedar habilitada en el registro a través de la nómina que presenta el proveedor, que no puede prestarle el servicio hasta que el BCRA notifique esa habilitación.
¿Una sociedad extranjera puede ser tomadora del servicio?
Solo si cumplió los requisitos de la Ley General de Sociedades 19.550 para actuar habitualmente en el país, porque a los tomadores les rigen las exclusiones del punto 1.3 del texto ordenado.
¿Quién responde ante el usuario si la cuenta falla?
La norma considera al usuario cliente del PSPCP en lo relativo al uso de la cuenta, pero el tomador puede quedar alcanzado por la responsabilidad solidaria del artículo 40 de la Ley 24.240 por haber puesto su marca en el servicio, siempre que el daño derive del vicio o riesgo de la prestación.
Estudio Lexar asesora a empresas de tecnología, fintechs y plataformas digitales en la estructuración de modelos de cuentas de pago con marca propia, la negociación de contratos con PSPCP y la adecuación de términos y condiciones, políticas de privacidad y procesos de onboarding a la normativa del BCRA, en el marco de su práctica de derecho informático.
