Preguntas Frecuentes

IPF - Icon Payments Framework. Es un marco de bajo código que permite a los bancos desarrollar su propia solución de procesamiento de pagos aprovechando el SDK de IPF y cualquier módulo opcional o listo que deseen.scheme pack s.

IPF es agnóstico a la nube (es decir, no depende de una plataforma de nube específica), pero no es nativo de la nube.

Módulos Opcionales Adicionales (AOM) proporcionan funcionalidad de soporte que está sujeta a una licencia adicional además de la IPF Core licencia.

Algunos ejemplos son

Para la lista completa y más detalles, por favor consulte AOM

Sí, los modelos de datos internos utilizados en los componentes y aplicaciones de IPF se basan en ISO20022 message type s.

Ninguno de los componentes, aplicaciones o soluciones de IPF construidos con IPF requieren ventanas de mantenimiento por defecto. Están diseñados de tal manera que soportan rolling upgrades con soporte de compatibilidad hacia atrás incorporado donde sea posible.

Las ventanas de mantenimiento son generalmente necesarias debido a los requisitos del entorno/infraestructura del banco o a los sistemas del banco que requieren dicho mantenimiento. Las soluciones de pago construidas con IPF deben ser capaces de soportar la indisponibilidad de esos sistemas dependientes gestionando el procesamiento de pagos en curso/nuevos de manera adecuada.

Sí, las soluciones de pago construidas con IPF y el soporte IPF applications apoya soluciones de múltiples entidades legales. El procesamiento de pagos y las vistas de datos de pagos están lógicamente segregados por entidad de procesamiento, que es un identificador para una entidad legal.

Los tutoriales son un excelente lugar para comenzar.- learn::home.adoc

IPF utiliza una referencia única (unitOfWorkId) para todas las transacciones procesadas, y puede asegurar que customer Las referencias proporcionadas están correlacionadas con las referencias internas de IPF para facilitar una reconciliación exitosa y proporcionar trazabilidad.

No, ambos instant y no-instant Las soluciones de pago pueden ser construidas utilizando IPF. El SDK también puede ser utilizado para desarrollar otras soluciones de procesamiento de pagos internas a una institución financiera.

No, las soluciones construidas con IPF pueden procesar pagos iniciados individualmente, en bulk, con fecha inmediata o futura. IPF también admite el procesamiento en días hábiles, así como ventanas de 24/7 y compensación respaldadas por los respectivos CSM service.

Sí, IPF no solo proporciona un conjunto de validaciones de pago técnicas y comerciales, también es posible que los bancos codifiquen custom validaciones comerciales que deben ser llamadas desde los flujos de procesamiento de IPF. Los pasos de proceso subyacentes en los flujos pueden integrarse con un sistema preexistente para realizar validaciones de pago.

IPF ha entregado una interfaz gráfica (Operational Dashboard) que proporciona la capacidad de buscar pagos/transacciones, ver el resumen/detalles de pagos, el historial de ejecución de pagos, el gráfico de ejecución en tiempo de ejecución, los mensajes en bruto intercambiados para un pago y más. No gestiona usuarios, pero admite el inicio de sesión único integrándose con el IAM del banco a través de OAUTH o SAML. También admite mapping los roles de la interfaz gráfica a los roles específicos del banco. Además de los datos de transacciones de pago, también hace API llamadas a varios IPF applications para obtener y actualizar dynamic settings y datos.

IPF Operational Dashboard se basa en el marco de trabajo de la interfaz gráfica de usuario de IPF, por lo tanto, es extensible. Los clientes pueden añadir sus módulos específicos del banco (pantallas y API integraciones) utilizando las características del marco de GUI de IPF y crear su propio customised/extender Operational Dashboard s.

IPF proporciona un conjunto de API definiciones para devoluciones, retiradas y ROIs. Para API definiciones ver IPF APIs

La implementación de tal APIs está sujeta a requisitos específicos del banco y puede definirse fácilmente como flujos de procesamiento dentro de una orquestación IPF. Los flujos pueden definirse en MPS usando Payments DSL y la integración de sistemas específicos del banco se puede lograr con el uso del conector IPF y mapping framework s.

Esta es la entidad para la cual se procesa un pago. Esto puede ser:

También se le conoce como Flo-lang.

La orquestación es una de las áreas clave donde IPF se distingue. Hemos construido nuestro propio lenguaje específico de dominio (DSL) para pagos, aprovechando JetBrains. MPS que permite a los clientes construir soluciones utilizando el DSL con una dependencia mínima de Icon. Consulte Marco de Orquestación y learn:tutorials:dsl_intro.adoc

Sí, hemos desarrollado nuestro propio Lenguaje Específico de Dominio (DSL) de bajo código aprovechando JetBrains. MPS. Puede ser utilizado tanto por usuarios empresariales como técnicos para definir customised flujos de procesamiento de pagos sin depender de un proveedor.

Usando Payments DSL, un banco podrá definir sus propios flujos de procesamiento de pagos según sus requisitos. Usando Payments DSL ofrece capacidades de orquestación claras y permite el uso directo de un ISO20022 modelo de datos canónico basado en el soporte para pagos.

Al definir sus flujos de orquestación, los clientes pueden agregar los modelos de datos requeridos del canon IPF.data library. Los modelos de datos específicos del cliente, donde sea necesario, pueden ser importados, lo que significa que los datos específicos del cliente podrían convertirse en parte del procesamiento, así como los modelos de datos canónicos genéricos de IPF.

El flujo está compuesto por estados y events, donde events proporcione el desencadenante para moverse entre estados.

El SDK y el DSL ofrecen una serie de características y funcionalidades:

Para más detalles sobre esto,Marco de Orquestación

Usando el MPS Editor de JetBrains y el IPF Payments DSL. Pruébelo learn::home.adoc

A domain event es un hecho crítico, el event significa que ha ocurrido algo específico que puede causar algún cambio en el procesamiento de nuestro pago. Domain events le ayuda a expresar, explícitamente, las reglas del dominio y se basan en el lenguaje ubicuo proporcionado por los expertos del dominio.

En las orquestaciones de IPF, domain events son partes críticas del procesamiento de pagos, declaradas explícitamente. Solo se publican si están registradas. Son inmutables. Se utilizan para cargar el actual state de un agregado (transacción) respondiendo grabado domain events sin efectos secundarios. También proporcionan el historial de ejecución - "¿Qué sucedió con la información de mi transacción?"

Sí, específico del banco system events puede ser definido siguiendo el IPF system events framework y el event estructura. Banco system events se definirá dentro de las implementaciones IPF específicas del banco. Para más información sobre cómo hacer esto, consulte Defina Events

IPF proporciona muchas características para apoyar el seguimiento, la monitorización y el archivo de pagos o datos de transacciones relacionadas.

Archivado: IPF puede proporcionar los datos de pago agregados y la información de procesamiento en el formato canónico de IPF publicado en un kafka tema (predeterminado) para que el banco pueda consumir y transformar/empujar la información a su sistema de archivo.

Crudo Message Log ging: Cualquier mensaje intercambiado durante un proceso de pago puede ser publicado en un sistema centralizado. Kafka tema y también registrado en IPF ODS(Operational Data Store). Estos mensajes pueden ser consumidos y publicados en la solución de auditoría centralizada del banco o pueden ser alimentados a ODS y accedido a través de ODS APIs. Estos también pueden ser mostrados a través de IPF Operational Dashboard pantallas como parte de la vista detallada de pagos.

Datos de Pago y Seguimiento: El IPF ODS vía APIs(o IPF Operational Dashboard s) proporciona búsqueda de pagos, vista de resumen de pagos, vista detallada de pagos y para cada pago un historial de ejecución que se compone de domain events registrado para ese pago durante el procesamiento, gráfico de ejecución en tiempo de ejecución de un pago, mensajes en bruto intercambiados por un pago. Consulte aom:ods:home.adoc para más información sobre ODS.

Las soluciones de pago construidas utilizando IPF también se benefician de la capacidad de crear específicos de banco.system events además de la lista predeterminada. System events Por defecto, se pueden exportar a archivos de registro. Estos archivos de registro pueden ser agregados utilizando una aplicación de recopilación de datos (por ejemplo, Splunk, ELK, etc.) y utilizados para un monitoreo adicional.

Métricas: Los componentes principales de IPF proporcionan una lista predeterminada de métricas técnicas y comerciales útiles de IPF que ayudan a monitorear la solución. Para la lista predeterminada de métricas de conectores y aplicaciones, consulte:Métricas.

Estas métricas son además de las predeterminadas. JVM métricas y también métricas proporcionadas por el Akka marco que es la tecnología subyacente de IPF core. En segundo plano, IPF utiliza la telemetría de Lightbend que, a su vez, utiliza Open Telemetry. API para exportar métricas a varios backends. IPF por defecto expone estas métricas a través de Prometheus, lo que significa que las métricas se exportan utilizando Prometheus exportadores y mostrados en Grafana Tableros, consulte Métricas de Series Temporales.

Registro: IPF utiliza Logback para la configuración de registros. Esto permite al usuario configurar un sistema de registro que puede reflejar el de otras aplicaciones desarrolladas dentro de la organización. Consulte Registro.

Sí

Los mensajes intercambiados para un pago se almacenan como parte de message log ging. Como parte del marco de conectores, al definir un conector,message log La implementación puede realizarse específicamente para los requisitos de implementación de un banco.

Los mensajes pueden ser publicados en un tema de procesamiento de datos centralizado. ODS ingestion, por ejemplo, consume de este tema y almacena los mensajes. Estos datos son consultables y ODS exponer APIs para recuperar mensajes para un pago dado. Además, IPF Operational Dashboard tiene una pestaña en la vista de detalles de pago que lista todos los mensajes intercambiados para el pago seleccionado, logrado mediante una consulta ODS Inquiry API.

Sí - ver pregunta-¿Es posible ver qué mensajes en bruto se intercambiaron para un pago?

IPF admite una variedad de mecanismos y protocolos de integración gracias a su Marco de Conectores, que es un marco estandarizado para definir conectores (integraciones) con sistemas externos/bancarios. Esto admite tanto integraciones síncronas como asíncronas, así como la mayoría de los protocolos de conectividad (MQ, Kafka,HTTP etc.) proporcionando integraciones altamente resilientes. El marco de conectores IPF admite mecanismos de recuperación automática, como reintentos configurables, presión de retroceso, limitación y más. Consulte Marco de Conectores para más información.

Además IPF Operational Dashboard soporta la integración con el IAM del banco a través de OAUTH/SAML para proporcionar la capacidad de inicio de sesión único. El marco de trabajo de la interfaz gráfica de usuario (GUI) de IPF, que ofrece la posibilidad de construir pantallas de interfaz de usuario específicas del banco, proporciona integración OAUTH/SAML/LDAP con el IAM del banco, de modo que cualquier interfaz de usuario construida utilizando el marco de trabajo de GUI de IPF soporte fácilmente el inicio de sesión único.

Como parte del SDK, IPF ofrece customisable enfoque de orquestación e integración, respaldado por su conector (Marco de Conectores) y mapping(IPF Mapping Framework) marcos. Lo que significa que el banco no se integra con IPF, sino que utiliza IPF para definir y construir aplicaciones de procesamiento de pagos que se integran con el banco y aplicaciones de terceros, ya sea de manera sincrónica o asincrónica. Lo hace utilizando formatos comunes de intercambio de datos (como XML or JSON) y una multitud de transportes (como HTTP, JMS, MQ, Kafka, etc).

Además, también hay un conjunto de aplicaciones de soporte listas para usar ofrecidas por IPF para soluciones de pagos. Estas aplicaciones proporcionan funciones comerciales reutilizables que pueden ser llamadas desde process flow s, en forma de APIs. La integración con estas aplicaciones es generalmente una combinación de HTTP or Kafka/mensajería APIs, en json formato.

También conocido como CSM Service, es un microservicio que aplica un Mecanismo de Compensación y Liquidación dado (CSM) manual de reglas. Esto incluye la conectividad y el modelo de datos para formatear los mensajes que se deben enviar y recibir de un mecanismo de compensación y liquidación dado, por ejemplo, RT1, STET, STEP2.

An IPF application que es responsable de proporcionar información sobre la accesibilidad de los participantes. También ofrece diversas funciones comerciales útiles a través de su APIs tales como obtener CSMs accesibles, deconstruir IBAN, validar BIC, seleccionar CSM agente así como la gestión de configuraciones APIs.

IPF viene con un Módulo Adicional Opcional (AOM) llamado Servicio de Resolución de Identidad, que aprovecha la tecnología de terceros de la empresa. NetOwl.

Como parte de este módulo, la solución es capaz de tomar el nombre y la dirección que están presentes en el mensaje de pago y compararlos con el nombre y la dirección que se encuentran en el *.customer sistema de información en el banco. El servicio devolverá una puntuación (que se calcula en base a algoritmos de lenguaje complejos) que es interpretada por el flujo según umbrales configurables para determinar el siguiente paso. Por ejemplo, si la puntuación está por debajo de 0.6 entonces eso podría significar que el pago es rechazado o enviado para intervención manual.

El servicio de notificación de estado de pago es una aplicación proporcionada como parte de IPF core y proporciona el estado de pago tipo Pain002 notifications para los pagos que se están procesando en una solución de procesamiento de pagos IPF.

Los canales bancarios suelen estar interesados en el estado de los pagos.notifications pero no desean ser inundados con cada pequeño cambio en el estado del pago. Pain002 notifications publicado por el servicio de Notificación de Estado de Pago son cambios más importantes. La definición de lo que constituye un cambio de estado importante es configurable en función de un filtro.

El servicio de notificación de estado de pago es responsable de consumir domain events desde el ipf-processing-data Kafka tema y basado en un filtro configurable publicando Pain002 notifications in Json formato a otro Kafka tema para que los sistemas bancarios lo consuman.

El IPF Operational Data Store (ODS) es la respuesta de IPF para habilitar vistas de datos a través de su procesamiento. Proporciona una unificación, y eventually una visión coherente del ciclo de vida completo de un pago. Esto será el resultado de la ejecución de múltiples procesos, como la iniciación, ejecución, compensación y liquidación, y cancelación. También incluirá la integración con otros sistemas bancarios, como las verificaciones de fraude y sanciones.aom:ods/home.adoc

An IPF application que proporciona una manera fácil y simple de gestionar tareas humanas que están registradas por flujos de procesamiento. Algunos ejemplos de tales tareas podrían ser aprobar o reparar un pago.

Estas 2 validaciones se logran mediante el uso de una Transacción. Cache(core:flo-starter:features/tx-cache.html), utilizado en la implementación para realizar la comparación de campos hasheados que deben ser especificados de acuerdo a customer requisitos.

Un ajuste de procesamiento dinámico (DPS) es un término de IPF para la configuración dinámicamente cambiante que se utiliza durante el procesamiento de un pago/transacción para que la actualización se aplique instantáneamente o scheduled se debe aplicar, pero en general no requiere aplicación restart para entrar en vigor.

Para que una configuración sea implementada como un DPS debe tener sentido desde la perspectiva del flujo de pago/transacción.

Para actualizar una configuración dinámica, puede ser necesario un proceso de aprobación, basado en un "requiere aprobación".flag. Esto proporciona una mayor flexibilidad para actualizar una configuración, ya que no todas las actualizaciones pueden requerir aprobación.

Algunos ejemplos de las aplicaciones que están utilizando DPS are:

Ver ¿Qué es el ODS?

También es posible almacenar y ver system events dentro ODS así mismo, sin embargo, para volúmenes más altos, se recomienda exportar system events en archivos de registro y mostrar a través de una herramienta de agregación de registros como Splunk, en lugar de utilizar ODS.

Estos API’s se utilizan por IPF Operational Dashboard para presentar los datos en forma de paneles operativos y de auditoría, pero también puede ser utilizado para extraer la información a sistemas externos como Pega, etc.

Procesando aplicaciones que están construidas con el registro de orquestación IPF domain events como hechos importantes relacionados con un pago y se puede configurar para publicarlos en un sistema centralizado Kafka tema: procesamiento-de-datos-ipf. Los datos de este tema pueden ser consumidos por una aplicación construida por el cliente para alimentar prácticamente cualquier otro sistema bancario según sea necesario.

Adicionalmente,ODS inquiry proporciona datos de pagos a través de ODS APIs desde las vistas consultables. Estos APIs puede ser utilizado y llamado para proporcionar los datos requeridos aguas abajo.

Es el valor del tamaño máximo del conjunto de búsqueda configurado para estar en ODS. El valor predeterminado es 1000.

IPF expone system events y también Prometheus métricas (siguiendo el estándar de Open Telemetry). Estas pueden ser utilizadas para extraer métricas, realizar comparaciones y mostrar en paneles de control utilizando Grafana.

Los componentes principales de IPF proporcionan una lista predeterminada de métricas técnicas y comerciales específicas de IPF que son muy útiles para monitorear la solución. Para la lista predeterminada de métricas de conectores y aplicaciones, consulte:Métricas.

Estas métricas son además de las predeterminadas. JVM métricas y también métricas proporcionadas por el Akka el marco que es la tecnología subyacente de IPF core. En segundo plano, IPF utiliza la telemetría de Lightbend y admite la exportación de métricas a varios backends.

IPF por defecto expone estas métricas a través de Prometheus, lo que significa que las métricas se exportan utilizando Prometheus exportadores y mostrados en Grafana Tableros. IPF Operational Dashboard también admite la visualización Grafana tableros como widgets como parte de las pantallas de la interfaz de usuario.

En muchas aplicaciones, a menudo existen requisitos relacionados con el mantenimiento de un registro de cada mensaje. Esto podría ser para fines de monitoreo, auditoría o almacenamiento de datos. Independientemente del caso de uso, la biblioteca de conectores proporciona una opción opcional message log instalación de mensajería que publicará tanto los mensajes enviados como los recibidos.

IPF utiliza Logback para la configuración de registros. Esto permite al usuario configurar un sistema de registro que puede reflejar el de otras aplicaciones desarrolladas dentro de la organización y hacer que IPF informe los datos de registro de la misma manera. Consulte Registro.

La orquestación de IPF y el marco de conectores proporcionan una variedad de mecanismos para hacer frente a fallos esperados y inesperados. Algunos ejemplos de estos mecanismos son:

La latencia para que un pago sea procesado dentro de una solución de pago construida con IPF depende principalmente de:

Los componentes principales de IPF están diseñados e ingenierizados para soportar aplicaciones de alto rendimiento y baja latencia con capacidades de resiliencia integradas.

En nuestras pruebas internas realizadas con una implementación bancaria hipotética (cliente-muestra), utilizando simuladores para sistemas bancarios y el CSM, con la correcta escalabilidad y configuración podemos lograr una latencia de transacción de extremo a extremo inferior a 2s dentro del percentil 99.

IPF ha sido diseñado desde cero para ser escalable. IPF solutions puede ser implementado de manera activa-activa en múltiples centros de datos.

El Akka El marco de actores permite que los componentes funcionales se comuniquen de manera transparente con otros componentes, ya sea que los componentes se encuentren en el mismo host o en otros hosts dentro del mismo centro de datos o entre centros de datos.

Escalado Vertical El despliegue de las soluciones utilizando IPF requiere planificación de capacidad y dimensionamiento de los servidores anfitriones teniendo en cuenta:

Escalado Horizontal La escalabilidad horizontal de IPF dentro de ese contexto se logra mediante el despliegue de:

Para apoyar la máxima disponibilidad, se recomienda implementar IPF solutions on to n n 1 AZs/datacenters.

Las aplicaciones/soluciones construidas con IPF generalmente requieren lo siguiente como mínimo para su implementación:

El enfoque preferido para ejecutar aplicaciones es utilizando contenedores en Kubernetes. Sin embargo, también es posible ejecutar en VMs y Openshift localmente.

Icon proporcionará el software IPF (en forma de un SDK) que un socio de SI o un banco utilizará para implementar la solución requerida en el propio entorno del banco y alojada por el banco.

Las aplicaciones de procesamiento de pagos basadas en IPF son independientes de la nube y actualmente están comprobadas en AWS. También es posible implementar soluciones construidas con IPF en las instalaciones.

La contenedorización en IPF es por defecto en Kubernetes, implementando Docker los contenedores, sin embargo, Openshift también es compatible.

Las aplicaciones construidas con IPF están diseñadas para soportar cero tiempo de inactividad.rolling upgrades.

Sin embargo, esto también está sujeto a implementaciones específicas del banco y customisations introducido por el banco.

También consulte learn:tutorials:home.adoc

Desde la versión V 2024.1(Mayo 2024), IPF utiliza Java 17/Primavera 6/Spring Boot 3 para todos los componentes de IPF (todas las versiones de IPF anteriores a esta están utilizando Java 11). Necesitará utilizar Java 17 en diseño, construcción y tiempo de ejecución.

IPF se basa en un conjunto de tecnologías bien conocido y ampliamente utilizado, lo que significa que la documentación para cada una de las tecnologías empleadas está en gran medida disponible en línea:

IPF proporciona documentación y tutoriales completos para permitir un aprendizaje autodidacta efectivo que complementa la formación dirigida por instructores y la capacitación práctica.

Los documentos IPF son documentos vivos y se mantienen dentro del mismo repositorio que el código. Por lo tanto, para cualquier actualización de lanzamiento, la documentación respectiva se actualiza de manera consistente.

La documentación para desarrolladores de IPF está disponible en este sitio.-

IPF también proporciona generación de documentos de flujo para soluciones. La definición del flujo se realiza en MPS usando Payments DSL Durante el proceso de construcción, IPF genera la documentación del flujo, la representación gráfica del flujo y los escenarios de prueba en forma BDD. Toda esta salida puede ser utilizada como parte de los documentos de implementación específicos del banco, eliminando la documentación manual para la orquestación.

Sí, la base de código de IPF se revisa periódicamente en nuestros escaneos de código internos como parte de nuestra pipeline de CI/CD para identificar cualquier vulnerabilidad:

IPF utiliza MongoDB base de datos que tiene sus propios mecanismos para asegurar los datos (Recurso:https://www.mongodb.com/docs/manual/security/[Seguridad de MongoDB]), le recomendamos el uso de MongoDB mecanismos de cifrado ya que no se utiliza cifrado adicional en el lado de IPF.

Para cifrar datos en rest,MongoDB Enterprise ofrece cifrado de clave simétrica basado en almacenamiento nativo, lo que significa que los usuarios pueden utilizar cifrado de datos transparente (TDE) para cifrar archivos de base de datos completos a nivel de almacenamiento. Se ofreció por primera vez en la versión 3.2, MongoDB utiliza el Estándar de Cifrado Avanzado (AES) Algoritmo de cifrado de 256 bits, un cifrado que utiliza la misma clave secreta para cifrar y descifrar datos. El cifrado puede activarse utilizando el modo FIPS, asegurando así que el cifrado cumpla con el más alto estándar y normativas.

Los archivos de la base de datos completos están cifrados utilizando el cifrado de datos transparente (TDE) a nivel de almacenamiento. Cada vez que se cifra un archivo, se genera una clave de cifrado privada única y es importante entender cómo se gestionan y almacenan estas claves. Todas las claves de la base de datos generadas se cifran posteriormente con una clave maestra. La diferencia entre las claves de la base de datos y la clave maestra es que las claves de la base de datos pueden almacenarse junto con los datos cifrados, pero para la clave maestra,MongoDB aconseja que se almacene en un servidor diferente de los datos cifrados, como soluciones de gestión de claves empresariales de terceros.

Para obtener más información sobre cómo configurar la encriptación de datos en rest por favor, consulte la documentación oficial MongoDB documentación (Recurso:https://docs.mongodb.com/manual/core/security-encryption-at-rest/[Cifrado en reposo]).

Si bien la encriptación mejora la seguridad, la desventaja es que introduce algunos impactos en el rendimiento, los cuales se describen en el siguiente artículo (Recurso:https://www.mongodb.com/blog/post/at-rest-encryption-in-mongodb-3-2-features-and-performance[Data-At-Rest Cifrado - Características y Rendimiento]).