24 noviembre 2023
Inteligencia Artificial, Banca
.jpg?ext=.jpg)
Así se titula el whitepaper que EBA Clearing ha puesto a disposición pública para que conozcamos un poco mejor este nuevo modelo que viene a innovar un poco más el mundo de los pagos digitales.
Nació como una solución para el pago asociado a la facturación electrónica, pero se trata de un esquema que encaja en multitud de casos de uso, tanto en comercio electrónico como en comercio físico. No se trata de un esquema que tenga como objetivo sustituir al de adeudos directos o el de transferencias SEPA basados en lotes, ni tampoco al pago con tarjeta.
El esquema cubre el conjunto de reglas operativas y elementos técnicos (incluidos los mensajes) que permiten a un Beneficiario solicitar el inicio de un pago de un Pagador en una amplia gama de casos de uso físicos u online.
Este puede considerarse como un complemento del flujo de pago porque respalda el proceso de extremo a extremo y se encuentra entre una transacción comercial subyacente y el pago en sí. Un RTP como tal puede verse como un habilitador de pagos digitales.
Alcance de la solución
El Esquema, que se basa en el documento de especificaciones elaborado por RTP Multi-Stakeholder Group (MSG RTP), cubre el conjunto de reglas operativas y elementos técnicos (incluidos los mensajes) que permiten a un Beneficiario solicitar el inicio de un pago de un Pagador en una amplia gama de casos de uso físicos o en línea. A lo largo de este documento, se asume que el instrumento de pago utilizado después de la aceptación del RTP es una Transferencia de Crédito.
No deja de ser una función de mensajería. No es ni un medio ni un instrumento de pago, sino una forma de solicitar un inicio de pago.
Además, se prevé que evolucione aún más con el tiempo para admitir funcionalidades más elaboradas, como ya se describe en el documento de especificaciones mencionado anteriormente.
Desde la perspectiva de la transmisión, el esquema es independiente del canal y el RTP puede transmitirse del Beneficiario al Pagador, a través de los participantes del Proveedor de Servicios RTP al Esquema por cualquier canal seguro. Además, el Pagador puede recibir directamente un RTP por parte del Beneficiario a través de varios entornos como tecnologías de proximidad, aplicaciones de mensajería, API dedicadas, etc.
Procesos de RTP y roles y entidades relevantes para RTP
El RTP debe considerarse como parte de la experiencia de pago de un usuario de un extremo a otro. Por ejemplo, al comprar bienes y servicios, independientemente de la variedad y complejidad de los procesos comerciales involucrados, se pueden distinguir los siguientes componentes básicos:
Los cuatro tipos de actores involucrados en el Esquema incluyen:
Este modelo es aplicado a los casos de uso básico, tanto físico como de comercio electrónico. En este modelo, tanto el Beneficiario como el Pagador utilizan su propio Proveedor de Servicios RTP. El Beneficiario puede enviar RTP a los Pagadores accesibles a través de entidades de enrutamiento. En cualquier caso, el identificador del Pagador y el Proveedor de Servicios RTP del Pagador debe ser conocido por el Beneficiario o el Proveedor de Servicios RTP del Beneficiario (antes de emitir un RTP), de modo que el Proveedor de Servicios RTP del Beneficiario pueda enrutar el RTP a Proveedor de servicios RTP del Pagador.
La versión actual del RTP es una funcionalidad atractiva que complementa el uso de transferencias de crédito para una mejor experiencia de usuario de pago de extremo a extremo en transacciones minoristas, transacciones EIPP (es decir, B2C, B2B y B2G) y transacciones P2P.
El RTP ayuda a optimizar la experiencia de pago de un extremo a otro para todas las partes involucradas y facilita la reconciliación. Además, el Esquema tiene como objetivo facilitar la solicitud de un pago de manera digital (incluida la interoperabilidad y accesibilidad) y permitir que los Beneficiarios expresen sus preferencias de pago (por ejemplo: pagar ahora / pagar después) alineadas con sus necesidades.
Los aspectos de tiempo inmediato y diferido ("now" o "later") se pueden asignar a la aceptación del RTP y al inicio del pago con los siguientes significados:
El RTP abre nuevas soluciones de implementación que cubren una amplia gama de casos de uso.
Calendario del SRTP
El 15 de Junio de 2021 se podrán realizar los primeros SRTP a través de Iberpay en España.
Para noviembre de 2021 se tiene planificado sacar ya una versión 2.0, en la que se incluyen las solicitudes de pagos de varias cuotas en un mismo envío.
Además de Iberpay, EBA Clearing como principal proveedor de la industria privada de servicios de infraestructura de pago paneuropeos, también proporcionará una solución para el nuevo esquema de pagos.
Nuestra visión
Desde BABEL vemos la implantación de este nuevo esquema como un paso más en la innovación del mundo de los pagos digitales. En la búsqueda constante por facilitar los mecanismos de pago al cliente final y buscar el mejor método para evitar cualquier tipo de fricción SEPA R2P se presenta como un claro candidato a complementar los modelos actuales basados en pagos con tarjeta, Bizum o de adeudos directos, buscando los casos de uso óptimos para su correcta aplicación.
Al tratarse de un modelo un poco diferente ya que no implica la realización de un pago como tal, sino la solicitud para una posterior emisión de una transferencia o pago inmediato y que tampoco implica la firma de un mandato o un plazo de 8 semanas para su devolución, podemos identificar numerosos casos de uso si contamos con un partner que nos facilite el acceso a este nuevo mundo.
El primero de ellos que se nos viene a la cabeza y que fue el origen de todo esto, tiene que ver con la emisión de la factura electrónica por los servicios prestados entre dos empresas lleve implícitamente una solicitud de pago mediante RTP.
A partir de aquí y pensando sobre todo en el sector Retail son numerosos los casos de uso que podemos llegar a identificar, pasando por el pago mediante un QR en una tienda física (pensando que avanzamos hacia una sociedad cashless) para personas que no disponen de una tarjeta o incluso tiendas que no disponen de un TPV o POS, hasta ver diferentes soluciones dentro del mundo e-Commerce para operar sin necesidad de introducir nuestro PAN o incluso buscando implementar soluciones de BNPL o basadas en múltiples “installments” o plazos.
No obstante, hay muchos más casos de uso que vendrán a cambiar los flujos actuales en el mundo de los pagos ya que seguramente otros actores que buscan una mayor inmediatez en el pago (como por ejemplo puede ocurrir con los modelos de franquicias o basados en intermediarios) o una reducción de costes operativos (como ocurre con los proveedores mayoristas) seguro le encuentran beneficios muy interesantes.
Nació como una solución para el pago asociado a la facturación electrónica, pero se trata de un esquema que encaja en multitud de casos de uso, tanto en comercio electrónico como en comercio físico. No se trata de un esquema que tenga como objetivo sustituir al de adeudos directos o el de transferencias SEPA basados en lotes, ni tampoco al pago con tarjeta.
El esquema cubre el conjunto de reglas operativas y elementos técnicos (incluidos los mensajes) que permiten a un Beneficiario solicitar el inicio de un pago de un Pagador en una amplia gama de casos de uso físicos u online.
Este puede considerarse como un complemento del flujo de pago porque respalda el proceso de extremo a extremo y se encuentra entre una transacción comercial subyacente y el pago en sí. Un RTP como tal puede verse como un habilitador de pagos digitales.
Alcance de la solución
El Esquema, que se basa en el documento de especificaciones elaborado por RTP Multi-Stakeholder Group (MSG RTP), cubre el conjunto de reglas operativas y elementos técnicos (incluidos los mensajes) que permiten a un Beneficiario solicitar el inicio de un pago de un Pagador en una amplia gama de casos de uso físicos o en línea. A lo largo de este documento, se asume que el instrumento de pago utilizado después de la aceptación del RTP es una Transferencia de Crédito.
No deja de ser una función de mensajería. No es ni un medio ni un instrumento de pago, sino una forma de solicitar un inicio de pago.
Además, se prevé que evolucione aún más con el tiempo para admitir funcionalidades más elaboradas, como ya se describe en el documento de especificaciones mencionado anteriormente.
Desde la perspectiva de la transmisión, el esquema es independiente del canal y el RTP puede transmitirse del Beneficiario al Pagador, a través de los participantes del Proveedor de Servicios RTP al Esquema por cualquier canal seguro. Además, el Pagador puede recibir directamente un RTP por parte del Beneficiario a través de varios entornos como tecnologías de proximidad, aplicaciones de mensajería, API dedicadas, etc.
Procesos de RTP y roles y entidades relevantes para RTP
El RTP debe considerarse como parte de la experiencia de pago de un usuario de un extremo a otro. Por ejemplo, al comprar bienes y servicios, independientemente de la variedad y complejidad de los procesos comerciales involucrados, se pueden distinguir los siguientes componentes básicos:
- Fase preparatoria que establece la transacción subyacente por la que se debe realizar un pago. (Esta parte está fuera del esquema SRTP)
- Creación y presentación del RTP al Pagador.
- Aceptación o rechazo del RTP. El Cliente (Pagador) puede aceptar el RTP, y esta Aceptación puede ir seguida de un pago inmediato o futuro, o rechazarlo.
- Proceso de pago, comenzando con el inicio del pago y la selección / confirmación del instrumento de pago, seguido de la ejecución del pago después de la Autenticación del cliente, según corresponda. (Esta parte está fuera del esquema SRTP)
Los cuatro tipos de actores involucrados en el Esquema incluyen:
- Beneficiario: El iniciador de un proceso de RTP y generalmente el beneficiario de los fondos transferidos en el flujo de pago resultante. Dependiendo del ámbito empresarial al que nos refiramos, este rol puede identificarse como el beneficiario cuando se trata de la tramitación del pago o el acreedor desde una perspectiva financiera.
- Pagador: Representa a la parte a la que se dirige el RTP y el originador de los fondos transferidos en el flujo de pago resultante. En el procesamiento de pagos, esta función generalmente se identifica con el originador de un pago, que también puede definirse como el deudor desde una perspectiva financiera. Un Pagador siempre debe tener la posibilidad de optar por no recibir el servicio RTP.
- Proveedor de servicios RTP del beneficiario: Generalmente representado por un PSP, pero dado que el RTP puede ser parte de los procesos de comercio de un extremo a otro, también otras entidades que no pertenecen al PSP pueden asumir esta función. Por lo tanto, los proveedores de servicios RTP del beneficiario pueden ser, por ejemplo: PSPs, Proveedores de servicios de facturación electrónica o Proveedores de servicios comerciales.
- Proveedor de servicios RTP del pagador: Al igual que en el caso del beneficiario, no solo un PSP puede ser su proveedor de servicios, sino también los proveedores de servicios de facturación electrónica y de servicios comerciales.
Este modelo es aplicado a los casos de uso básico, tanto físico como de comercio electrónico. En este modelo, tanto el Beneficiario como el Pagador utilizan su propio Proveedor de Servicios RTP. El Beneficiario puede enviar RTP a los Pagadores accesibles a través de entidades de enrutamiento. En cualquier caso, el identificador del Pagador y el Proveedor de Servicios RTP del Pagador debe ser conocido por el Beneficiario o el Proveedor de Servicios RTP del Beneficiario (antes de emitir un RTP), de modo que el Proveedor de Servicios RTP del Beneficiario pueda enrutar el RTP a Proveedor de servicios RTP del Pagador.
- Identificación del pagador: Una primera interacción permite la comunicación del identificador del Pagador y el identificador del Proveedor de Servicios RTP del Pagador.
- RTP hacia el proveedor de servicios del beneficiario: El beneficiario envía el RTP a su proveedor de servicios RTP. Contiene todos los datos básicos de RTP, incluido el identificador del pagador.
- RTP hacia el proveedor de servicios del pagador: El RTP se envía a través de la red de proveedores de servicios entre RTP.
- Presentación del RTP al pagador: El RTP se presenta al Pagador en su canal o dispositivo acordado (por ejemplo teléfono inteligente, navegador web, etc.)
- Reporte del estado: La Aceptación / Rechazo del RTP por parte del Pagador se devuelve al Beneficiario a través del entorno del Proveedor de servicios entre RTP.
- Modelo 3-corner: En este modelo, el beneficiario y el pagador utilizan un proveedor de servicios RTP común que proporciona un mecanismo de enrutamiento centralizado.
- Modelos “directos”: En estos modelos, una llamada solicitud de pago es un RTP "simplificado" que se intercambia directamente entre el Beneficiario y el Pagador (por ejemplo, a través de estándares de mensajería API). Los modelos directos se basan en enlaces directos entre el Beneficiario y su Pagador, lo que permite la presentación del RTP en el dispositivo del Pagador.
La versión actual del RTP es una funcionalidad atractiva que complementa el uso de transferencias de crédito para una mejor experiencia de usuario de pago de extremo a extremo en transacciones minoristas, transacciones EIPP (es decir, B2C, B2B y B2G) y transacciones P2P.
El RTP ayuda a optimizar la experiencia de pago de un extremo a otro para todas las partes involucradas y facilita la reconciliación. Además, el Esquema tiene como objetivo facilitar la solicitud de un pago de manera digital (incluida la interoperabilidad y accesibilidad) y permitir que los Beneficiarios expresen sus preferencias de pago (por ejemplo: pagar ahora / pagar después) alineadas con sus necesidades.
Los aspectos de tiempo inmediato y diferido ("now" o "later") se pueden asignar a la aceptación del RTP y al inicio del pago con los siguientes significados:
- Accept now: el RTP debe aceptarse de inmediato.
- Accept later: el RTP se puede aceptar más tarde.
- Pay now: el Pagador debe pagar el RTP inmediatamente, en el momento de la aceptación.
- Pay later: el pago se inicia en un plazo posterior al tiempo de aceptación.
El RTP abre nuevas soluciones de implementación que cubren una amplia gama de casos de uso.
Calendario del SRTP
El 15 de Junio de 2021 se podrán realizar los primeros SRTP a través de Iberpay en España.
Para noviembre de 2021 se tiene planificado sacar ya una versión 2.0, en la que se incluyen las solicitudes de pagos de varias cuotas en un mismo envío.
Además de Iberpay, EBA Clearing como principal proveedor de la industria privada de servicios de infraestructura de pago paneuropeos, también proporcionará una solución para el nuevo esquema de pagos.
Nuestra visión
Desde BABEL vemos la implantación de este nuevo esquema como un paso más en la innovación del mundo de los pagos digitales. En la búsqueda constante por facilitar los mecanismos de pago al cliente final y buscar el mejor método para evitar cualquier tipo de fricción SEPA R2P se presenta como un claro candidato a complementar los modelos actuales basados en pagos con tarjeta, Bizum o de adeudos directos, buscando los casos de uso óptimos para su correcta aplicación.
Al tratarse de un modelo un poco diferente ya que no implica la realización de un pago como tal, sino la solicitud para una posterior emisión de una transferencia o pago inmediato y que tampoco implica la firma de un mandato o un plazo de 8 semanas para su devolución, podemos identificar numerosos casos de uso si contamos con un partner que nos facilite el acceso a este nuevo mundo.
El primero de ellos que se nos viene a la cabeza y que fue el origen de todo esto, tiene que ver con la emisión de la factura electrónica por los servicios prestados entre dos empresas lleve implícitamente una solicitud de pago mediante RTP.
A partir de aquí y pensando sobre todo en el sector Retail son numerosos los casos de uso que podemos llegar a identificar, pasando por el pago mediante un QR en una tienda física (pensando que avanzamos hacia una sociedad cashless) para personas que no disponen de una tarjeta o incluso tiendas que no disponen de un TPV o POS, hasta ver diferentes soluciones dentro del mundo e-Commerce para operar sin necesidad de introducir nuestro PAN o incluso buscando implementar soluciones de BNPL o basadas en múltiples “installments” o plazos.
No obstante, hay muchos más casos de uso que vendrán a cambiar los flujos actuales en el mundo de los pagos ya que seguramente otros actores que buscan una mayor inmediatez en el pago (como por ejemplo puede ocurrir con los modelos de franquicias o basados en intermediarios) o una reducción de costes operativos (como ocurre con los proveedores mayoristas) seguro le encuentran beneficios muy interesantes.
.png?width=300&height=400&ext=.png)
Otros artículos destacados
.png?ext=.png)
¡Recibido!
Gracias por rellenar el formulario. Se han enviado los datos correctamente.
