Interoperability

Connecting platforms, identities, data and financial services

Connection needs shared meaning and authority

Interoperability is the ability of participants and systems to work together for a defined service. Technical connectivity is one layer. Shared data meaning, permissions, business rules, financial arrangements and dispute handling determine whether a connection produces a useful outcome.

Two systems can accept the same JSON or XML structure and still interpret status, currency, time or customer authority differently. An API response that another system parses is not proof that the payment settled or that the recipient can use the funds.

Payment interoperability

Define participants, identifiers, routing, currencies, liquidity and settlement arrangements. Different systems may have different operating hours, limits, finality and exception processes. Link instruction references and statuses so the customer's request remains traceable across boundaries.

ISO 20022 supports financial-message modelling and definitions. It is not itself a payment scheme or a guarantee that all implementations use identical fields and rules. Applicable usage guidelines, versions and business semantics still need alignment.

Authorisation, clearing, settlement and availability are distinct. An internal wallet transfer and an external bank payout can have different timing for valid reasons. Disclose actual service expectations and charges rather than promising universal instant movement or assuming every boundary delay is unlawful.

Data and identity interoperability

Data sharing needs relevant permission or another applicable lawful basis, defined scope and reliable interpretation. Account access, payment initiation and retained financial records are different subjects. Withdrawal should reach affected processing under the applicable arrangement; it does not automatically undo settled payments or require deletion of every legally retained record.

Identity credentials need an accepted trust framework, valid issuer and appropriate assurance for the task. A credential accepted by one firm is not automatically sufficient for another's entire customer due-diligence process. Examine expiry, revocation, presentation security, recovery and the recipient's responsibilities.

Share only needed information. Cryptographic verification can establish properties of a credential without proving every associated fact is current or that the presenter has authority for a financial action. Reducing repeated proofing can help usability, but reduced fraud is an outcome to measure, not an automatic guarantee.

Governance and change

Name who owns standards, conformance tests, admission, certification, version migration and incident resolution. Document field definitions and permitted errors. Test precision, duplicate handling, timeout enquiry and partial failure. Reliable financial effects usually need idempotency and reconciliation, even when messaging systems offer particular delivery guarantees.

Commercial agreements should explain fees, availability, obligations and exit. Interoperability does not universally require identical prices or unlimited participation. Evaluate whether the actual access model works and satisfies the relevant framework.

Fictional example: successful message, unresolved payout

A wallet sends a bank payout and receives a technical acknowledgement. Its app displays completed before receiving the relevant execution status. The recipient reports no usable funds. Investigation joins the original reference and authoritative records rather than sending an unverified duplicate.

The firms correct the status mapping and test delayed and conflicting messages. The lesson is semantic and operational interoperability: connection success was only one step in the financial task.

Takeaway

Measure cross-participant task success, unexplained breaks, case resolution and version failures. Interoperability works when meaning, trust and financial effects survive the system boundary.

Continue to Future Bank Operating Models.