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: the ledger 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:

• Posted balances (end-of-day, settled)
• Account ownership and status (open, dormant, closed)
• The official transaction ledger after settlement

What the core is NOT good at: real-time views. Cores traditionally run batch processing, meaning transactions are collected and posted in scheduled runs (often overnight). So the balance in the core at 2pm may not reflect a coffee you bought at 1:55pm.

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.

Card switches and payment rails: the money-in-motion layer

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:

• ACH (Automated Clearing House): batch bank-to-bank transfers in the US, payroll and bills.
• Fedwire and CHIPS: high-value US wires.
• FedNow and RTP: instant US payments, settling in seconds, 24/7.
• SEPA in the Eurozone, and TARGET2 / T2 for large-value euro settlement.
• SWIFT: the messaging standard for cross-border payments.

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.

Digital channel logs: behavior, not balances

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:

• How many customers abandoned the wire transfer form?
• Which device did the login come from?
• Did the customer view the fee disclosure before complaining?

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: the external view

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, GDPRGDPREU regulation governing how organizations collect, store and use personal data, with fines tied to global revenue for breaches.View full definition → and national rules apply.

Putting it together: the authoritative-source mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition →

The core skill: for any question, name the system of record.

When two systems disagree, this map 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.

A worked reconciliation example

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):

• Card switch reports 10,000 authorizations totaling $430,000
• Core posts 9,850 settled transactions totaling $421,000

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.

Data qualityData qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → across the estate

Each layer fails in its own way. Know the common defects:

• Core: duplicate customer IDs after mergers, stale batch balances mistaken for real time.
• Card switch: authorizations with no matching settlement (dangling records).
• Channel logs: events with no resolvable account key, bot traffic inflating counts.
• Bureau: stale files, mismatched identities (thin-file or fuzzy name matches).

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.

Where the data physically lives in 2026

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 platformSoftware that unifies customer data from every source into one persistent profile that marketing, sales and service teams can act on.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.

Key takeaways

• Name the system of record for every question. Balances live in the core, authorizations in the switch, settlement in the rail, behavior in channel logs, external debt in the bureau.
• Timestamps are not interchangeable. Transaction date, posting date, authorization time, and settlement time are different fields from different systems. Confusing them breaks reconciliation.
• Reconcile across layers. A same-day auth-to-posting settlement rate around 98% or higher is typical; a sudden drop signals a data feed failure, not a business event.
• Bureau data is lagged and legally gated. It reports monthly and requires a permissible purpose under the FCRA (US) or GDPR (EU).
• The golden record is a stitched view, not the truth. For authoritative answers, always trace lineage back to the origin system.