En nosotros a través de CSM determinación

Esta página explica cómo customise el manejo de transacciones On-us a través de la CSM.

Context

Tradicionalmente, cuando ambas partes están con el mismo banco, la liquidación ocurre internamente en lugar de a través de un esquema.

En algunos casos, sin embargo,customers puede querer enviar pagos a sí mismos a través de un esquema. Esto se conoce como on-us-via-CSM.

Identificación de On-us a través de CSM

Por defecto, un pago se considera interno si el BIC del deudor es el mismo que el BIC del agente acreedor. Este la funcionalidad puede ser insuficiente en casos como:

  • El CSM el servicio al cliente está hablando con múltiples CSM implementaciones de servicio

  • La determinación on-us es más compleja (por ejemplo, verifique contra una lista de BICs en lugar de solo uno a uno).

  • El objetivo CSM No utilice BICs, o la comparación debe realizarse contra más campos.

La siguiente implementación está definida por defecto en el CSM Service biblioteca del cliente:

    @Override
    public boolean isCreditTransferOnUs(FIToFICustomerCreditTransferV08 fi2fi) {
        return Try.of(() ->
                        fi2fi.getCdtTrfTxInf().get(0).getDbtrAgt().getFinInstnId().getBICFI()
                                .equals(fi2fi.getCdtTrfTxInf().get(0).getCdtrAgt().getFinInstnId().getBICFI()))
                .getOrElse(this::failedToDetermine);
    }

    @Override
    public boolean isStatusRequestOnUs(FIToFIPaymentStatusRequestV03 fi2fi) {
        return Try.of(() -> fi2fi.getTxInf().get(0).getOrgnlTxRef().getDbtrAgt().getFinInstnId().getBICFI()
                        .equals(fi2fi.getTxInf().get(0).getOrgnlTxRef().getCdtrAgt().getFinInstnId().getBICFI()))
                .getOrElse(this::failedToDetermine);
    }

Y el bean se define como tal:

    @Bean
    @ConditionalOnMissingBean
    public OnUsDeterminer onUsDeterminer() {
        return new DefaultOnUsDeterminer();
    }

Si desea anular esta funcionalidad para implementar un custom funcionalidad de determinación en nosotros en lugar de el predeterminado, cree uno nuevo OnUsDeterminer implementación, y crear un bean con el mismo nombre y firma, para utilizar su customimplementación en lugar de la predeterminada.

Tenga en cuenta que si no se implementa en nosotros a través del CSM no es necesario deshabilitar ninguna funcionalidad en us.

Detectando On-us a través de CSM

Si el OnUsDeterminer determina que un pago es interno a través de CSM, establecerá un booleano en el SupportingContext llamado `onus`que puede ser inspeccionado al manejar cualquier respuesta:

    @Override
    public CompletionStage<Void> handleClearAndSettleResponse(final ReceivingContext receivingContext, final ClearAndSettleResponse response) {
        var onus = Boolean.parseBoolean(response.getCustomBusinessData().getMetaData().getValues().get(ON_US));
        if (onus) {
            // do on-us-specific stuff
        } else {
            // normal clear-and-settle response handling
        }
    }

Manejo de On-us a través de CSM dentro de un IPF flow

Un desafío común con on-us a través de CSM está reconociendo qué mensaje corresponde a qué flujo. Esto se debe a que ciertos mensajes, específicamente pacs.002 Los mensajes pueden ser utilizados en diferentes situaciones como parte de una transacción de transferencia de crédito:

Número de secuencia Tipo de pacs.002 mensaje IPF API Mensaje Dirección Propósito

1

Acreedor PSR

ReceivePaymentResponse

IPF a CSM

Aceptar/rechazar un pago

2

Deudor PSR

ClearAndSettleResponse

CSM a IPF

Respuesta de aceptación/rechazo del agente acreedor

3

Confirmación de PSR del Acreedor

ReceivePaymentSettledRequest

CSM a IPF

Notificación de liquidación final

En muchos esquemas de pago, el pacs.002 los mensajes en 2 y 3 se verán idénticos, así que CSM Services no se puede determinar cuál CSM mensaje mapas a los cuales IPF API mensaje, y puede etiquetar incorrectamente ambos como ClearAndSettleResponse. Esto significa que el acreedor pierna de un en-nosotros-a-través-de-CSM el pago puede permanecer incompleto:

onus-via-csm-bad

Existen varias maneras de reinterpretar el tercero pacs.002 como un ReceivePaymentSettledRequest. A continuación se presenta una sugerencia enfoque:

¡Procesamiento adicional!

Implementar la sugerencia a continuación introduce un procesamiento adicional. Para evitar problemas de rendimiento con procesando pagos normales, asegúrese de realizar únicamente lo siguiente cuando onus is true como los pasos adicionales a continuación son innecesario para el procesamiento normal de pagos.

Cuando handleClearAndSettleResponse se llama y onus is true, consulte el estado de la transacción del deudor (using getAggregate()):

  1. Si el flujo de deudores no está completo, reenvíe al flujo de deudores.

  2. Si el flujo del deudor está completo:

  3. Mapee el ClearAndSettleResponse(Deudor PSR) a un ReceivePaymentSettledRequest(Acreedor PSR Conf)

  4. Determine el flujo del acreedor AssociationId--ODS or TransactionCacheService o de otro modo)

  5. Reenvíe al flujo del acreedor

onus-via-scheme-opt1

La secuencia anterior debería resultar en que tanto los flujos del deudor como del acreedor se completen, ya que tienen todos los mensajes relevantes. que están esperando.