CSM Reachability - Cambios y Soluciones

Esta página cubre los cambios y correcciones proporcionados a CSM Reachability Liberación de IPF 2025.3.0

CSM Reachability API

Cambiado

  • Campo booleano opcional añadido rMessage con valor predeterminado false en la solicitud a los puntos finales:

    • /v2/select-csm-agente

    • /v2/validate-csm-alcanzabilidad

  • Los mensajes R son tipos de transacciones específicos como devoluciones, reversos, recuperaciones y rechazos.

  • Algunos participantes en el sistema están configurados con el 'rMessageOnly’flag, lo que significa que están disponibles para el procesamiento de transacciones R-message.

  • El rMessage flag en las solicitudes controla cómo se evalúan a los participantes durante la verificación de participación.

  • Cuando el rMessage flag está configurado como VERDADERO en la solicitud:

    • La validación aceptará tanto a los participantes regulares como a los participantes rMessageOnly.

    • Todos los participantes pueden proceder a través de los pasos de validación de alcanzabilidad.

  • Cuando el rMessage flag está configurado como FALSE o no se proporciona en la solicitud:

    • La validación solo aceptará participantes regulares.

    • Los participantes marcados como rMessageOnly no pasarán la verificación de participación.

    • No se devolverá ninguna ruta para los participantes de rMessageOnly.

  • El proceso de validación no genera fallos ni excepciones cuando los participantes no son accesibles. En su lugar, la respuesta indicará que no hay ruta disponible, y los criterios de accesibilidad en la respuesta mostrarán qué paso de validación no se cumplió.

Este cambio es compatible hacia atrás, por lo que funcionará sin enviar rMessage en la solicitud e incluso sin tener el campo rMessageOnly en la base de datos. Los valores predeterminados serán falsos para ambos campos.

CSM Reachability

Nuevo

  • CSM Reachability Service ahora introduce una nueva opción de configuración tanto para la Deconstrucción de IBAN como para la Validación de BIC (búsqueda de PartyEntity). Por defecto, el servicio continúa utilizando la antigua fuente SWIFTRef para la Deconstrucción de IBAN (IBAN Plus, Estructura de IBAN y Lista de Exclusión) y la Validación de BIC (Bic Dir2018).

  • Para cambiar a la nueva fuente de datos de la industria (SWIFTRef_Identifiers_All), establezca lo siguiente:

# Dos modos posibles:
# "legacyPortfolio" → Opción antigua-utiliza ExclusionList + IBAN Plus únicamente para la Deconstrucción de IBAN y Bic Dir2018 para la Validación de Bic
# "evolvedPortfolio" → Nueva opción-utiliza la búsqueda de PartyEntity tanto para la Deconstrucción de IBAN como para la Validación de BIC
#
# El valor predeterminado es la forma antigua ("legacyPortfolio")
 ipf.csm-reachability.swift-ref-version = "evolvedPortfolio"
  • Es importante señalar que todos los servicios (puntos finales) que llamen a la Deconstrucción de IBAN también se verán afectados por este cambio.

Antes de habilitar la nueva opción, es necesario ingerir todos los datos requeridos de *SWIFTRef_Identifiers_All* (`IDENTIFIERS-ALL` y `FORMATS-CTRY/FORMATS-ALL` archivos descritos en la parte de Ingesta de Datos a continuación).

La deconstrucción del IBAN debería funcionar como se espera en la mayoría de los casos, pero se puede derivar un BIC de IBAN incorrecto cuando el valor de Identificación Nacional del IBAN coincide en más de un sistema de compensación / país. Este es un problema conocido y se solucionará en la próxima versión. Las implementaciones de los clientes pueden utilizar el portafolio evolucionado de SWIFTRef con fines de prueba, pero deben esperar a que se solucione y se publique el error PAY-15778 antes de que se utilice el portafolio evolucionado de SWIFTRef en entornos en VIVO.

  • Se añadieron nuevos campos e índices buscables para la colección de Entidades de Parte:

    • entityUniqueId-ibanId

ipf.dps.mongodb.index-config.partyentity {
 index-14 = ["values.payload.entityUnique Id:ASC"]
 index-15 = ["values.payload.ibanIdentifiers.ibanId:ASC"]
}
  • Añadido lastUpdatedAt como índice predeterminado en todas las colecciones de configuraciones.

ipf.dps.mongodb.index-config.<tipo-de-ajuste> {
 index-x = ["lastUpdatedAt:ASC"]
}

Soporte a la Entidad de Procesamiento

Se admite ahora un parámetro processingEntity opcional en todos los relevantes. Dynamic Processing Settings(DPS) puntos finales. Los llamantes pueden pasar este parámetro para asegurar que:

  • Solo se leen o actualizan los datos que pertenecen al PE especificado.

  • Los datos que pertenecen a otros PEs son invisibles (la API se comporta como si esos registros no existieran).

Si se omite el parámetro,APIs comportarse exactamente como antes.

El parámetro puede ser proporcionado ya sea en el cuerpo de la solicitud o como un parámetro de consulta/ruta, dependiendo del punto final específico.

Para más detalles sobre el manejo de entidades de procesamiento en DPS puntos finales utilizados por configuraciones dinámicas en CSM reachability service, por favor consulte IPF-2025.3.0 - DPS Notas de la versión para la funcionalidad.

Cambiado

Modelo de entidad de parte actualizado

  • Nuevos campos en la Entidad de Parte

    • parentEntityId

    • groupEntityId

    • routingIdentifiers (swiftFinPlusBic & swiftFinPlusDn)

    • ibanIdentifiers (ibanId & ibanBic)

  • La configuración de la clave lógica única de PartyEntity es diferente dependiendo de la fuente de donde provienen los datos. Si los datos provienen de un archivo IDENTIFIERS-ALL, entonces la clave lógica única es la combinación de la fuente de datos, el valor del identificador, el tipo de identificador y el id único de la entidad. Si los datos provienen de otras fuentes, entonces la clave lógica única es la combinación de la fuente de datos, el país y el id único de la entidad.

Modelo IbanStructure actualizado

  • Nuevos campos en la estructura de Iban

    • iban Tipo De Identificación Nacional

    • ibanNationalIdPosition

CSM Modelo de participante actualizado

  • campo routingBIC marcado como Obsoleto, pero aún mapeado para algunos CSM Directorios para fines de compatibilidad hacia atrás

  • nuevo campocsmMemberId - El Id del miembro según lo especificado por el CSM. Esto puede no ser un identificador de la industria utilizado en los pagos, sino un código que CSM asigna para identificar a un miembro que participa en el CSM utilizando múltiples identificadores de la industria. Esto puede ser un código de miembro común asignado por el CSM a un miembro mientras el miembro puede tener múltiples identificadores de participante bajo él.

  • nuevo campodirectParticipantDetails - Detalles del participante que posee la cuenta de liquidación. Para los participantes indirectos, este atributo puede contener los detalles de los participantes directos.

  • nuevo camporoutingDetails - Los identificadores que pueden ser utilizados para diferentes propósitos: Estándar- para el enrutamiento de los pagos al participante; Devolver- para el enrutamiento de devoluciones al participante; Redirección- para el enrutamiento de los pagos o devoluciones donde están disponibles los identificadores de enrutamiento de "Redirección"

    • csmMemberId agregado a los campos buscables, por lo que se recomienda que se cree un índice para este campo

  • nuevo campo booleanorMessageOnly - El valor de true indica que un participante SOLO puede recibir Rmessages (devoluciones, reversos, recordatorios, rechazos); un valor false significa que el participante puede recibir cualquier/todas las transacciones. El valor predeterminado es false.

Obtenga entidades de partido y lógica de búsqueda de entidades de partido

  • Actualizó la lógica para obtener los detalles de la Entidad de Parte:

    • La entidad de la fiesta de la oficina central se selecciona principalmente si existe.

    • Para SWIFTRef_Identifiers_All fuente de datos, los identificadores se unen de todos los registros de la Entidad Parte con el mismo entityUniqueId.

Determinar el Identificador del Participante de la Entidad de Procesamiento

Lógica de extracción de identificadores de participantes para la búsqueda de entidad de procesamiento:

  • para participantes directos - Se devuelve el valor del Identificador del Participante, con el Tipo de Configuración del Agente y el Subtipo.

  • para el Participante indirecto - Los Identificadores de Participantes se obtienen de sus Detalles de Participante Directo.

  • para Participantes heredados-se utiliza el BIC de enrutamiento, con el Identificador BIC, Identificador Subtipo SCHEME_MEMBERSHIP_BIC

Ingesta de Datos

Nuevo

  • Ingesta de SWIFTRef IDENTIFIERS-ALL archivo para la colección de Entidades de Parte. Cada entrada del archivo representa un registro de Entidad de Parte con un identificador de entidad. La Fuente de Datos de Entidad para este tipo de ingestión es SWIFTRef_IDENTIFIERS-ALL.

  • Ingesta de SwiftRef FORMATS-ALL y FORMATS-CTRY archivos a la colección de Estructura de Iban. Hay dos nuevos campos que se están mapeando en los datos de Estructura de Iban a partir de estos archivos,ibanNationalIdType y ibanNationalIdPosition.

  • A continuación se proporciona una configuración importante respecto a la ingestión de estos nuevos archivos:

 ipf.csm-reachability.party-entity.identifiers {
 habilitado = verdadero
 file-ingestion {
 directory-id = "identificadores-de-entidad-de-partido"
 files-directory = "import/party-entity-directory/party-entity-identifiers/"
 }
}
 ipf.csm-reachability.iban-estructura.formatos {
 habilitado = verdadero
 file-ingestion {
 directory-id = "iban-structure-formats"
 files-directory = "import/iban-plus-directory/iban-structure-formats/"
 }
}
ipf.file-ingestion.directory-mappings+= {
 "directory-id": "identificadores-de-entidad-de-partido",
 "job-name": "Importación de Identificadores de Entidad de Fiesta"
}
ipf.file-ingestion.directory-mappings+= {
 "directory-id": "iban-structure-formats",
 "job-name": "Importación de formatos de IbanStructure"
}
  • Estos nuevos archivos SwiftRef pueden presentarse como archivos completos, de delta diario y de delta mensual con banderas de modificaciones de A/M/D. También pueden contener registros futuros con fecha de inicio en el futuro, que serán interpretados como scheduled ajustes.

Se recomienda que las implementaciones del cliente realicen pruebas con la funcionalidad evolucionada de SWIFTRef (búsqueda de entidad de parte, deconstrucción de IBAN) utilizando versiones completas de los archivos de SWIFT. Icon no tiene acceso a archivos completos. Si bien el nivel de confianza en el desarrollo de la función realizado con archivos de muestra es alto, las pruebas utilizando archivos de muestra no someten al producto a todas las posibles variabilidades de datos que ofrecen los archivos completos. Cualquier problema observado durante las pruebas de archivos completos debe ser comunicado a Icon para que pueda ser abordado antes de que el uso evolucionado de SWIFTRef sea habilitado en VIVO por las implementaciones del cliente.

Cambiado

  • Clave Única Lógica para CSM Los registros de participantes se actualizan a continuación:

    • CSMAgent Id

    • CSMParticipant Identifier

    • ParticipantType (si está presente)

  • Mapeo para el archivo TIPS - Campos del Participante:

    • routingBIC→ mapeado desde accountOwnerBIC (en lugar de partyBIC)

    • csmMemberId→ mapeado desde partyBIC

    • routingDetails→ mapeado desde accountOwnerBIC

    • directParticipantDetails→ mapeado desde accountOwnerBIC, cuando el participante es INDIRECTO

  • Ingesta completa de archivos RT1 y STEP2 - Los registros con estados CAMBIADOS y R-ÚNICO están siendo procesados además de los registros actualmente procesados con estado HABILITADO.

    • si el registro tiene el estado HABILITADO, entonces el Participante tendrá el campo rMessageOnly establecido en falso-si el registro tiene el estado CAMBIADO o R-ÚNICO, entonces el Participante tendrá el campo rMessageOnly establecido en verdadero

    • El valor de rMessageOnly como verdadero indica que un participante SOLO puede recibir Rmessages (devoluciones, reversos, recordatorios, rechazos).

  • La ingestión de archivos locales ahora tiene una nueva propiedad de configuración.timestamp-archived-and-failed-files con valor predeterminado establecido en true. Esto significa que ahora, por defecto, añadimos marcas de tiempo a los archivos que terminan en /archive y /failed directorios. (p. ej.,file_20251020_143530.xml). Esto puede desactivarse configurando la propiedad en falso. La configuración predeterminada de ingestión de archivos ahora se ve así:

 default-file-ingestion {
 files-directory = "/import"
 initial-delay = 5s
 intervalo = 30s
 timestamp-archived-and-failed-archivos = verdadero
 }
Este cambio para RT1 y la ingestión completa de archivos STEP2 es compatible hacia atrás. No es necesario ningún script de migración para la base de datos, ya que se utilizan Mongo/CosmosDB, los documentos se guardarán sin problemas con o sin este nuevo campo.rMessageOnly. La ausencia de este campo se tratará como si tuviera un valor falso.

Cambios Importantes

  • Se recomienda encarecidamente que el siguiente conjunto de archivos que se ingrese en CSM Participante después de asumir la liberación 2025.3 son archivos COMPLETOS. Cualquier archivo delta puede reanudarse después de la ingestión de archivos completos, pero el primer conjunto de archivos que se debe ingerir después de esta versión debe ser archivos completos.

  • Se recomienda encarecidamente que todos los procesos de ingestión de archivos SwiftRef (IDENTIFIERS-ALL y FORMATS-ALL/FORMATS-CTRY) se realicen principalmente como ingestión de archivos COMPLETOS para que todas las estructuras de datos relevantes se actualicen adecuadamente.

  • Clase de configuración de pruebas BDD com.iconsolutions.ipf.dynamicsettings.test. SharedSteps constructor cambiado

    • Se añadió un nuevo parámetro:`List of Request Types`, al constructor de SharedSteps.

    • Esto se hizo con el fin de apoyar las pruebas de futuros API versiones.

    • Si está utilizando esta clase, o extendiéndola, por favor actualice su código en consecuencia, por ejemplo:

      public E2ESteps e2ESteps(CommonTransportSteps commonTransportSteps, DynamicProcessingSettingsBaseSteps baseSteps, SettingApiClient settingApiClient) {
      List<RequestTypeInterface> requestTypes = new ArrayList<>();
      requestTypes.addAll(Arrays.stream(SettingManagementApiRequestType.values()).toList());
      requestTypes.addAll(Arrays.stream(ReachabilityApiRequestType.values()).toList());
      return new E2ESteps(commonTransportSteps,baseSteps, settingApiClient, requestTypes);
      }..

Rendimiento

Rendimiento Recomendado para Bank Directory Plus en Cosmos DB

Configuraciones recomendadas para la ingestión de la Entidad de Fiesta:

  • Rendimiento:30000 RUs (esquema de Cosmos DB)

  • Paralelismo:16(ipf.csm-reachability.settings-api.direct.parallelism en ConfigMap)

Estos valores se determinaron a través de pruebas de rendimiento. Son importantes para la ingestión de un BANKDIRECTORYPLUS full file (~1.5 millones de registros), reduciendo el tiempo de ingestión de aproximadamente 175 minutos a aproximadamente 45 minutos.

Rendimiento recomendado para el archivo IDENTIFICADORES-ALL de la entidad Party en Cosmos DB

Rendimiento recomendado para la ingestión de la entidad de partido para IDENTIFIERS-ALL archivo completo:

Tamaño del archivo: ~4.9 millones de registros, pero después de algunas operaciones de filtrado, se ingestan 3 115 384** registros.

  • Rendimiento:30000 RUs (esquema de Cosmos DB)

  • Paralelismo:

  • Paralelismo directo:`8`(ipf.csm-reachability.settings-api.direct.parallelism en ConfigMap)

  • Paralelismo de identificadores de entidades de partido:`5`(ipf.csm-reachability.settings-api.party-entity-identifiers.parallelism en ConfigMap)

  • Paralelismo de entidades de partido:`8`(ipf.csm-reachability.settings-api.party-entity.parallelism en ConfigMap)

Estos valores se determinaron a través de pruebas de rendimiento, con un tiempo de ingestión ~160 minutos .

Para ambos Bank_Directory_Plus y SWIFTRef_IDENTIFIERS-ALL fuentes de datos, ajuste según sea necesario, de acuerdo con las futuras pruebas de carga y los requisitos comerciales.