I have reviewed integration estates at KSA banks where the same format translation exists in three different places: once in IBM ACE, once in an Apache Camel route added when the team moved to OpenShift, and once in a Python script that a developer wrote to unblock a deadline and which has been quietly running in production for eighteen months. Each translator is slightly different. None of them is wrong, exactly. All three produce a valid pacs.008. But when SAMA updates the IPS purpose code table, all three need to be updated — and the Python script is the one that gets missed.

The canonical data model is the architectural decision that prevents this. Not the code — the decision. The code is an implementation detail. The decision is: there is one internal representation of a payment in this bank, one team owns its schema, and every integration flow translates to that representation on the way in and from it on the way out. That decision, made once and enforced consistently, eliminates the purpose-code-table update problem entirely. There is one place to change the mapping, one place to update the validation rules, and one place to add the new SAMA-mandated field when the next specification revision arrives.

Why most banks never make this decision

The canonical data model pattern has been in the enterprise integration literature since Gregor Hohpe and Bobby Woolf published Enterprise Integration Patterns in 2003. Every enterprise architect knows the pattern. Most integration estates at KSA banks do not have a governed canonical model. The reason is not ignorance. The reason is that the pattern requires a decision that is easy to defer: who owns the schema?

Building the first canonical model is a weekend’s work for a competent engineer. Maintaining it — fielding change requests from eight different teams, reviewing whether a new SAMA Open Banking field belongs in the canonical or in a flow-specific extension, deciding what to do when the CDM conflicts with a legacy core format that cannot be changed — is an ongoing function that requires designated ownership, a defined change process, and the authority to say no to fields that do not belong in the canonical layer. Without that governance structure, the canonical model grows into an unmaintainable blob, teams stop trusting it, and the point-to-point translators come back.

The CDM is not a technical debt problem. It is an ownership problem. Banks that have a functioning canonical model almost invariably have a named Integration Architect who reviews every CDM change request. Banks that do not have a functioning CDM almost invariably have nobody whose job includes that review.

The trade-off leadership has to make explicit

A canonical data model introduces a dependency: every integration flow must use the CDM module, which means every flow is affected by a breaking CDM change. This is a real cost. A flow that was independently deployable becomes coupled to the CDM release cycle. Teams that prefer microservice autonomy resist this coupling.

The trade-off leadership has to make explicit is: what is the cost of that coupling versus the cost of the alternative? The alternative is not autonomy — it is hidden coupling. A bank with twelve format translators that all implement the SAMA purpose code mapping independently is not loosely coupled; it is tightly coupled to twelve different implementations of the same logic, with no single place to coordinate a change. When SAMA publishes a spec update, the coordination cost is paid twelve times, and the risk of inconsistency is real.

The CDM makes the coupling explicit and managed. That is a trade-off worth making for any bank running more than four or five integration flows that touch the same payment formats. At the scale of a commercial bank connected to SAMA IPS, BUNA, SWIFT, a core banking system, and one or more Open Banking TPP channels, the CDM is not an architectural luxury. It is the minimum structure required to maintain coherence when the regulatory environment changes.

What SAMA regulation implies for CDM design

SAMA’s IPS Technical Specifications and the SAMA Open Banking Framework impose specific data requirements that appear in multiple payment paths. A domestic IPS credit transfer requires an ISO 20022 purpose code. A SAMA Open Banking payment initiation carries a localInstrument code that maps to a purpose code. An MT103 arriving from a SWIFT correspondent carries neither — the purpose code must be derived from the payment type or the originating channel.

Without a canonical model, each of these derivation rules lives in a different place. With a canonical model, the derivation rule lives once: in the enrichment pipeline that populates the CDM purposeCode field before the outbound pacs.008 adapter reads it. When SAMA updates the purpose code list, there is one update, one test, one release. The question leadership has to answer is not whether the canonical model is the right architecture — it obviously is, for this class of problem. The question is whether the governance structure that keeps it alive will be funded and staffed, or whether it will be treated as an engineering function that does not need designated ownership.

What the team needs from leadership

Three things, in order of importance:

A named CDM owner with review authority. This does not have to be a dedicated headcount. It can be the principal integration architect who also does other things. What matters is that the role is named, the CDM change review is an explicit responsibility, and the owner has the authority to reject a change request that would make the CDM incoherent. Without named ownership, the CDM accretes fields until it collapses under its own complexity.

A SAMA spec monitoring process. SAMA publishes specification updates through the participant portal and through banking circulars. Someone has to read those updates, identify which ones affect the CDM, and raise a CDM change request before the effective date. This is a low-frequency but high-consequence function. The team that built the integration is the right team to own it; they need confirmation from leadership that monitoring SAMA spec updates is part of their ongoing remit, not something they do when they have spare capacity.

A change release cadence that does not require a programme board. Minor CDM changes — adding an optional field, updating a purpose code mapping — need to move faster than a quarterly release cycle. SAMA sometimes publishes a spec update with a shorter effective window than that. The integration team needs a lightweight release path for CDM minor versions that does not require going through the full change management process. This is a governance decision, not a technical one: the CDM owner and the relevant change manager agree on which CDM changes qualify as minor and can go through the fast track.

For the engineering depth behind this topic — entity taxonomy design, Java 21 CDM implementation, IBM ACE JavaCompute wiring, Apache Camel TypeConverter binding, schema versioning, and the production failure modes the documentation does not cover — see the companion Lab article: Canonical Data Model: Designing a Bank-Wide Mapping Layer.