Author: Dr. Gulzar Singh, Chartered Fellow in Banking & Technology
Yet beneath those advances, a quieter problem persists.
Data still means different things in different places.
The same customer action - a payment, a balance change, a fee, a loan event - is often described differently depending on the system handling it. What looks like a technical detail quickly becomes an operational issue. Reconciliation effort increases. Regulatory reporting slows. Confidence in management information weakens.
Over time, this inconsistency becomes normal.
This is where the Common Domain Model (CDM) matters for retail banking - not as a technical abstraction, but as infrastructure.
The hidden cost of inconsistent meaning
Retail banks operate across deposits, loans, cards, payments, savings, and increasingly embedded financial services. Each domain has allowed its systems, vendors, and data definitions to evolve independently.
Duplication follows.
A simple deposit might appear as a “credit” in one system, an “incoming transaction” in another, and a “balance update” somewhere else. Each label may be locally accurate. Collectively, they create friction.
Teams spend time translating rather than acting.
The operational impact accumulates quietly. Regulatory submissions take longer because data must be normalised manually. Risk teams struggle to trace events end to end. Audit relies on sampling instead of confidence. Technology teams build mappings that break when platforms change.
In practice, speed is constrained not by compute power, but by trust in data.
CDM as shared language, not shared system
The Common Domain Model was developed in capital markets to address a similar challenge: the absence of a common, machine-readable language for describing financial products and lifecycle events.
Its value lies in what it does not attempt to do.
CDM does not replace systems. It does not mandate vendors. It does not centralise platforms. Instead, it provides a consistent semantic layer - a shared way of describing what has happened.
Applied to retail banking, this distinction is critical.
A payment initiation, a balance change, or a fee application can be described once, in a standardised form, and reused across functions. Meaning remains stable even when systems differ.
The problem shifts from integration to agreement.
Operational clarity and regulatory confidence
Consistency of meaning has immediate operational consequences.
When events are described the same way across systems, reconciliation becomes simpler. Exceptions are easier to identify. Root causes surface faster.
For regulators, traceability matters more than speed alone. Confidence depends on the ability to follow an event through its lifecycle without reinterpretation at every hand-off. CDM supports this by anchoring reporting to a common structure.
This extends beyond compliance. Management information improves when leaders are comparing like with like, rather than reconciled approximations assembled late in the cycle.
Over time, operational risk reduces not through additional controls, but through clearer foundations.
Interoperability without centralisation
Retail banking increasingly depends on interoperability - between internal platforms, fintech partners, payment schemes, and third-party services. APIs have improved connectivity, but they have not solved semantic alignment.
Systems connect. Meaning still diverges.
CDM addresses this gap by acting as a shared reference point. When combined with communication standards such as FDC3, systems can exchange context as well as data.
This matters in practical settings. Branch and contact-centre staff routinely move between applications during a single customer interaction. Today, that movement involves rekeying, rechecking, and reinterpreting information. Standardised event definitions reduce that friction.
Interoperability becomes operational rather than aspirational.
A pragmatic path to adoption
Retail banks do not need wholesale transformation to benefit from CDM.
Incremental adoption is more effective. The starting point is identifying areas where inconsistency is most costly - payments reconciliation, onboarding events, fee processing.
Mapping a single high-friction process to CDM allows institutions to test impact without disruption. Improvements in speed, accuracy, and transparency can be measured and shared internally.
Because CDM is open source and community-maintained, adoption does not create vendor dependency. It aligns naturally with regulatory expectations around resilience, openness, and shared infrastructure.
Each use case strengthens the model. Each contribution benefits the ecosystem.
Why this matters now
Retail banking is entering a phase where complexity can no longer be absorbed quietly. Cost pressure, regulatory scrutiny, and customer expectations are converging.
Institutions that rely on bespoke translations and manual reconciliation will struggle to move quickly and safely.
CDM offers a different approach: invest once in shared meaning and reuse it everywhere. The return is not just efficiency, but confidence - confidence that systems, data, and decisions are aligned.
Capital markets have already demonstrated the value of this path. Retail banking has the opportunity to follow, without repeating the same mistakes.
The constraint is no longer technology.
It is collective intent.
Explore CDM:
Author: Dr. Gulzar Singh, Chartered Fellow in Banking & Technology