# Mapping the banking data estate across core, channels and bureaus
A customer calls to dispute a $47 charge from last Tuesday. Where does the "truth" of that transaction live? Not in one place. The card network saw it first, the core banking system posted it, the mobile app showed it, and a fraud engine scored it. Five systems, five timestamps, five slightly different versions of the same event.
Knowing which system is authoritative for which question is the single most useful skill in banking data work. This lesson maps the estate so you can always name the source of record.
The core banking system (often just "the core") is the master ledger. It holds accounts, balances, and the posted transactions that move money. Think of it as the general ledger for every customer relationship.
Major cores in 2026 include FIS, Fiserv, Temenos, and Jack Henry, plus newer cloud-native players like Thought Machine and Mambu. Large banks often run several cores stitched together after decades of mergers, which is why a single customer can exist as three different IDs.
What the core is authoritative for:
What the core is NOT good at: real-time views. Cores traditionally run
Key distinction for any analyst: posting date (when the core recorded it) versus transaction date (when it happened). Confusing these breaks reconciliation and fraud analysis.
Before a transaction reaches the core, it travels through networks.
A card switch is the system that routes and authorizes card transactions in real time. When you tap a card, the switch checks funds, applies limits, and returns an approve/decline in under two seconds. The switch talks to the networks: Visa, Mastercard, and in the US domestic debit routing under Regulation II (the Durbin Amendment rules governing debit interchange and network choice).
Payment rails are the pipes money moves through. Naming the main ones for 2026:
Why this matters for data: authorization data (from the switch) and settlement data (from the rail and core) are separate datasets with separate timestamps. A card authorization can be approved and then never settle. If you count authorizations as revenue, you overstate it.
The industry is standardizing messaging on ISO 20022, a structured format that carries far richer payment data (full remittance details, structured addresses) than legacy formats. For data teams this is a gift: cleaner, more machine-readable payment records. The ISO 20022 resource centre has the free specifications.
Every tap in the mobile app and every click in online banking generates channel logs or event streams. This is clickstream data: login events, page views, funds-transfer attempts, failed logins, device fingerprints.
Channel data answers behavioral questions the core cannot:
This data usually lands in an event pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → (Kafka is common) and then a data lakedata lakeA data lake is a centralized repository that stores large volumes of raw data in its native format, from structured tables to unstructured files, until needed.View full definition → or warehouse (Snowflake, Databricks, BigQuery). It is high-volume, semi-structured, and often lacks a clean account key, so joining it to the core requires an identity resolution layer.
Channel logs are also central to fraud and security. A login from a new device in a new country, followed by a beneficiary change and a large transfer, is a classic account-takeover pattern visible only in channel data.
Credit bureaus hold data on how consumers borrow and repay across all their lenders. In the US the big three are Equifax, Experian, and TransUnion. In the UK it is Experian, Equifax, and TransUnion again; other European markets have national bureaus (for example SCHUFA in Germany).
Bureau data is external and authoritative for one thing: a customer's borrowing behavior with other institutions. It powers credit scoring (the US FICO and VantageScore models draw on bureau files).
Two data realities to respect:
1. Bureaus are not real time. Lenders typically report monthly, so a bureau file can lag actual behavior by weeks.
2. Bureau data is heavily regulated. In the US the Fair Credit Reporting Act (FCRA), enforced by the Consumer Financial Protection Bureau (CFPB) and the FTC, governs accuracy, dispute rights, and permissible purpose. You cannot pull a bureau report without a lawful reason. In the EU, GDPR and national rules apply.
The core skill: for any question, name the system of record.
| Question | Authoritative source |
|---|---|
| What is the settled balance? | Core banking |
| Was this card payment authorized? | Card switch |
| When did the wire actually settle? | Payment rail (Fedwire/RTP/TARGET2) |
| What device logged in at 2:03pm? | Channel logs |
| What is the customer's total external debt? | Credit bureau |
| Who legally owns this account? | Core banking |
When two systems disagree, this mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → tells you which one to trust for that specific field. That is the whole game in data lineagedata lineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.View full definition →: tracing a data point back to its origin system.
Reconciliation is comparing two datasets that should agree. Here is the most common one: card authorizations versus core postings.
Assume for a single day (illustrative figures, not real bank data):
The gap:
Auth count 10,000 - Posted count 9,850 = 150 unposted items
Auth value $430,000 - Posted value $421,000 = $9,000 unsettled
Settlement rate = 9,850 / 10,000 = 98.5%A 98.5% same-day settlement rate is normal: some authorizations drop off (a hotel hold released, a declined capture, a merchant that never settled). The job is explaining the 1.5%, not panicking. If the rate suddenly fell to 90%, that signals a feed failure between the switch and the core, a genuine data-quality incident.
Knowledge check
1. An analyst investigating a disputed charge finds that the mobile app, the card switch, and the core banking system each report slightly different details about the same transaction. What is the most accurate conclusion to draw from this?
2. A customer buys coffee at 1:55pm and checks their account balance in the core banking system at 2:00pm, but the purchase is not reflected. What best explains this?
3. Why is the distinction between posting date and transaction date critical for an analyst doing reconciliation or fraud analysis?
4. Select ALL correct answers about what the core banking system is authoritative for.
Select all the correct answers.
5. Select ALL correct answers explaining why a single customer might exist under multiple different IDs within one bank.
Select all the correct answers.
Each layer fails in its own way. Know the common defects:
A practical data-quality metric to track per feed is completeness: the share of expected records that actually arrived. If the core normally receives about 500,000 daily transaction records from the switch and one morning it gets 400,000, completeness is 80% and you have a broken feed before any customer complains.
The BCBS 239 principles (a Basel Committee standard on risk-data aggregation for large banks) push exactly this discipline: accuracy, completeness, and timeliness with clear lineage. It applies to major banks, but its checklist is good practice everywhere.
Most large banks now run a hybrid model: cores and payment systems on-premises or private cloud (latency and regulation demand it), with channel logs, bureau extracts, and analytics in a cloud lakehouselakehouseA hybrid architecture combining the flexibility of a data lake with the analytical capabilities of a data warehouse, on a single storage layer.View full definition →. The customer data platformcustomer data platformA Customer Data Platform unifies customer data from all sources into persistent, actionable profiles that other systems can use.View full definition → or golden record layer sits on top, resolving identities across cores so "Jane Smith" in three systems becomes one customer.
That golden record is not a source of truth itself. It is a stitched view. When you need the authoritative answer, you still trace back to the origin system.