Processing Entity Enrichment

When receiving inbound files from scheme as we do not know what entity they are destined for they need to be enriched with a processing entity as they are debulked (processed).

This scheme pack offers a number of processors to handle this enrichment; the processors available are:

  • NoOp - utilise a default fallback-entity value (enabled out-of-the-box)

  • Config - utilise a data structure supplied in config of direct and indirect participant(s)

  • CSM Reachability - utilise your own deployed CSM Reachability setup to call during processing

Overview

A high level overview of how the processing entity is enriched is seen in the diagram below.

Diagram

Notes

  1. This criteria is always built and accessible in the same form for all the processors so you can plug-and-play with each type without having additional changes needed

  2. The ProcessingEntityEnrichmentLookupFailed (see List of System Events) system event can be emitted for a number of scenarios which include:

    • Not just ONE processing entity was resolved

    • CSM Reachability was not able to process the request (unaccessible, internal error, etc.)

    • No processing entities were resolvable (missing/incorrect static config, CSM Reachability configuration missing for participant(s))

    • CSM Reachability returned a reason code and description, see the Reason Codes reference for the full list

CSM Reachability

This requires you to have deployed and configured the CSM Reachability service; see here

CSM Reachability allows you to define a hierarchy of processing settings which includes matching processing entities for direct and indirect participants. This processor will utilise the API endpoint /determine-processing-entity (OpenAPI specification and operation overview) Once you have CSM Reachability configured and running you can supply the below configuration to the scheme pack:

ipf {
  csm-reachability-api {
    http.client {
      host = "<reachability-host>"
      port = "<reachability-port>"
    }
  }

  csm.sepa-ct.processing-entity {
    processor {
      enabled = true
      type = "reachability"
    }
  }
}

Config

This assumes you have added valid agent BICs; as shown in example below

The valid-agent-bics config block is already used in the Validations, to use config you enrich those rules with the processing entity; if your BIC is matched, but you have not supplied a processing entity, it will fall back to ipf.csm.sepa-ct.processing-entity.processor.fallback-entity which out-of-the-box has a value of "UNKNOWN"

processing-entity is nullable if you’re defining the valid-agent-bics structure for validation usage only 
ipf.csm.sepa-ct.processing-entity {
  processor {
    enabled = true
    type = "config"
  }

  valid-agent-bics = [
    {
      direct-participant {
        bic = "VALIDBIC0"
        processing-entity = "BIG_BANK_0"
      }
      indirect-participant-bics = [
        {bic: "VALIDBIC1", processing-entity: "BIG_BANK_MINI_1"}
      ]
    }
  ]
}

NoOp (Default)

This processor will use the fallback-entity as shown below.

Due to nature of the setup, you can only define one fallback entity as this is also used in scenarios where one exact match cannot be resolved (for the other processor types).

Enabled out-of-the-box, without supplying or overriding the config below will result in this processor being used

You can set the fallback-entity to utilise the same processing entity used in debulker by setting:

fallback-entity = ${ipf.csm.sepa-ct.debulker.processing-entity}

 
ipf.csm.sepa-ct.processing-entity {
  fallback-entity = "UNKNOWN"
  processor {
    enabled = false
  }
}