Customer 360 Data Model for Retail Banking: Entities, Identity Keys and a Sample Schema

A customer 360 banking data model describes the entities a bank needs to see one customer consistently across products and channels: the party, household, accounts, product holdings, transactions, interactions, consents, risk flags, cases and campaign exposures, tied together by identity keys and survivorship rules. In a customer data platform (CDP) it is a governed, derived view of the customer; the cores remain the system of record.

This page is for data architects, governance leads and DPOs. It gives the entities, keys, retention rules, PII tags, sample schemas and event names, then maps them to BIAN. It belongs to the financial services hub; the platform and regulatory context is in customer data platforms for banks.

Entities and relationships

Three modelling rules keep the structure honest. Product holding is a separate entity so that joint accounts and signatories are not forced into a single owner field. Household is a relationship with validity dates, not a merged party. Every record carries its source system and both valid time and recorded time, so the bank can reconstruct what it knew on a given date.

Identity keys and survivorship rules

Match deterministically first. Use probabilistic matching only for non-regulated marketing analytics, with review, and never to merge identities that carry KYC status. Treat household inference as a relationship, not a merge. See identity resolution explained.

Golden record versus operational truth

The golden record is a derived, point-in-time view with provenance, not a replacement for the cores. The cores stay authoritative for balances, postings, product terms and KYC status. The CDP is authoritative for marketing consent, campaign exposure and its own derived attributes. Three practices follow.

1. Set freshness per attribute. Consent and deceased status need near-real-time propagation; segment membership can tolerate batch.
2. Keep history. Store previous and new values with timestamps and the user or process that changed them. Salesforce's guide for APRA-regulated firms makes the same point about reconstructing consent status before a campaign 1.
3. Snapshot decisions. Record the exact features and rule versions used at decision time, so a decision can be replayed even after the profile changes.

Write-back to cores should be limited to governed APIs for specific attributes, such as contact preferences, and never for KYC fields. See single customer view for the regulatory uses of a unified view.

Retention and legal hold

| Marketing profile attributes | Storage limitation (Art. 5(1)(e)) 4 | Delete or anonymise when the purpose ends | | Behavioural events | Purpose and consent | Short window; aggregate before archiving | | Campaign exposure | Complaint handling and fair-treatment evidence | Retain for a period set in policy |

PII classification tags

Enforce tags in a schema registry: the collector rejects untagged fields, retention jobs read the tag, and egress policy references it.

Sample schema tables

These tables are illustrative, not a complete physical model.

party

product_holding

consent_record

interaction_event

Event taxonomy examples

Name events as object_action in snake case, version each schema, validate properties at ingestion, and allow no free text.

How BIAN and industry models relate

BIAN, the Banking Industry Architecture Network, is a membership body of more than 100 banks, software vendors and consultancies, and its portal describes a service landscape (version 14.0 announced on 13 March 2026) 6. BIAN is a capability and API model. It names what a bank does and where responsibilities sit; it does not give you a physical schema. FIBO, the Financial Industry Business Ontology, is hosted by the EDM Council and standardised by OMG; it defines financial business concepts and their relationships in OWL and can give shared meaning to data models 7. Vendor models also exist, for example Salesforce's Financial Services Data Kit, which provides data model objects for core banking and insurance 8.

A pragmatic approach: use BIAN to name domains and set ownership boundaries, FIBO for vocabulary where definitions are disputed, and keep the CDP's physical model small. The service-domain names below come from BIAN's version 12 landscape 9.

Governance checklist

1. Every entity has a named authority system and a data owner.
2. Every field has a PII tag, enforced at ingestion.
3. Survivorship rules are documented, versioned and tested.
4. Merges and unmerges are logged with reason and actor.
5. Consent changes keep previous values and evidence.
6. Retention clocks run per purpose; legal hold blocks deletion.
7. Freshness targets exist for consent, status and deceased flags.
8. No PAN, authentication data or KYC documents are ingested.
9. The model inventory lists every score and segment used in a decision.
10. Row- and field-level access follows line-of-business boundaries.
11. Schema changes pass change management with downstream impact review.
12. Data-quality metrics (match rate, duplicate rate, verified-contact coverage) are reported monthly.

What a Customer 360 enables: dashboards and metrics

Next-best-action decisions consume the same entities; see real-time next best action inside the bank. For the wider pipeline, see customer data platform architecture and consent withdrawal across channels.

To review how this model would sit on your own infrastructure, request a private infrastructure review.