Designing a global payment solution with multi-entity support

15 January 2025

While using the IPF tool kit to implement a payments solution for a tier 1 international banking group with a presence across the globe we were faced with the challenge of designing a solution with a single deployable code base across multiple geographic regions and separate legal entities. The central requirement was that the same code (applications/services) could be deployed in all regions and through configuration alone be enabled for use by different banking entities within the group. Let’s talk about multi-entity support.

What is multi-entity?

Many readers will already be familiar with the concept of multi-tenancy. This is an architecture in which a single instance of a software application serves multiple customers.

A typical IPF implementation will only be related to a single customer, however the principles of multi-tenancy may still be applied. Many large banks operate a number of processing entities. Processing entities may represent different legal entities or even separate business lines. While it is important that payments for different processing entities are kept separate, and one entity’s payments (and customer data) cannot be accessed by another entity it is beneficial to be able to use shared infrastructure and processing resources to manage these payments. This is where IPF’s multi-entity support comes in.

Value of a multi-entity solution

Designing a solution that has multi-entity concerns as a central principle, encourages reuse and reduces development costs. Architecting and building for multiple processing entities from the start, results in a solution that is much easier to scale for more entities as your business expands or as you wish to roll your IPF solution out to other regions.

Logical vs physical segregation

When implementing a multi-entity solution there are two key considerations, logical and physical segregation.

Logical

The concept of a processing entity is a core feature of the IPF data model. Configuration of clearing and settlement mechanisms as well as many other values are made in the context of a processing entity.

Data associated with payment processing is tagged with a processing entity ID. As a result, a single operational data store can be used to hold payments data from multiple different processing entities with filters combined with user attributes to control access when data is queried. This is a key feature of IPF data architecture and simply requires the implementation to provide the correct processing entity ID when initiating a payment flow.

Physical

There are times when logical segregation is not enough. For example, it is highly likely that different processing entities will maintain separate Customer Information (CI) systems. In such cases we would say that the CI data is physically segregated. IPFs flexible connector SDK enables an implementation to interact with physically segregated external domains from a single multi-entity deployment

Separation of responsibilities

When constructing payment processing flows with IPF, it is important to apply the principle of separation of responsibilities. The flow must be responsible for defining the states and workflow transitions required to process a payment, it should be decoupled from the specifics of how those states must be implemented.

E.g. A typical state in a payment processing flow will involve some form of debtor validation, i.e. determine that the account exists, is enabled for the particular product, has sufficient funds, etc. The flow should not be concerned with which system of record should be looked up to perform these checks.

Different processing entities may have different client Information systems requiring different interfaces to perform these checks. The details of how to interact with a processing entity specific system can be hidden behind a façade providing a common interface. It is possible then to select the correct façade to interact with based on processing entity when processing a specific payment.

Example components to support this principle

  • Connector factory
    • Centralised configuration allowing multiple services/applications to benefit while consolidating configuration
    • Supports physical segregation by allowing processing entity specific configurations.
    • Hides the selection of appropriate processing entity connectors at runtime from processing flows.
    • Enables processing entity independent security configuration for connections.
  • Domain clients
    • Encapsulate the technical interactions with external domains.
    • Provide a standard interface and hide the processing entity specific implementation.

Recommendations

  • Configure or inject processing entity IDs.
    DO NOT hardcode in flows
  • Everything is an array.
    Even if you only have 1 processing entity or 1 instance of an external domain today, consider them as 1 item in an array as this will make it much easier to extend later as your implementation grows.
  • Consider using a connector factory from the start of your project
    Using a connector factory moves the logic of maintaining connectors out of the flow and results in more focus on the business logic.
  • Centralise connector configuration
    Maintaining copies of connector configuration for different applications introduces maintenance overhead and the opportunity for misalignment of configuration.
  • External domain facades
    Simplify flows by having a single Interface contract with external domains. Use a facade to transform that interface to processing entity specific requirements.

 

If you would like to find out more about IPF or how Icon can help you, get in touch.

Taffy Brecknock

BACK TO BLOGS