# Mapping the fintech data landscape: sources, vendors and refresh cycles
A lending app approves a borrower on Monday using a credit file that was last updated three weeks earlier. By Friday, that borrower has maxed out two new credit lines elsewhere. The app's risk model never saw it coming, not because the model was bad, but because the data feeding it was stale. This is the quiet failure mode of fintech: not broken code, but mismatched refresh cycles across the data supply chain.
This lesson builds a mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → of that supply chain: who supplies what, how often it updates, and what it costs. Understanding this mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social. is a core fluency skill for anyone working in or around fintech.
Fintech products are assembled from external data feeds, not built from scratch. Four categories dominate.
Credit bureau data. In the US, the three major bureaus are Equifax, Experian, and TransUnion. They aggregate lender-reported tradeline data (credit cards, loans, mortgages) into credit files and scores like FICO. In Europe, the landscape is fragmented by country: Experian and Schufa (Germany) are examples, with no single pan-European bureau. Bureau files typically refresh on a monthly cycle because lenders report to bureaus roughly monthly, though some "trended data" products update more granularly.
Bank account aggregators. Plaid, MX, and Yodlee (Europe's equivalents include TrueLayer and Tink, both built under the EU's Open Banking rules via PSD2, the Second Payment Services Directive) let apps pull a user's bank transaction history and balances with consent. Refresh cycles vary from real-time APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → pulls to daily batch syncs, depending on the bank's own core banking system and the aggregator's polling frequency.
Card network data. Visa and Mastercard process authorization and settlement data essentially in real time for transaction approval, but the richer "enriched" transaction data (merchant category codes, location tags) used for analytics products often arrives with a lag of hours to a day.
Device and behavioral signals. Fraud and identity vendors like Sift, Socure, and LexisNexis Risk Solutions combine device fingerprinting, IP geolocation, and behavioral biometrics (typing cadence, swipe patterns). These signals are near-real-time by necessity: fraud decisions happen in milliseconds during checkout.
A single product often blends data updating at wildly different speeds. Consider a buy-now-pay-later (BNPL) underwriting model:
| Source | Typical refresh cycle | Risk if stale |
|---|---|---|
| Credit bureau file | Monthly (estimate) | Misses recent debt accumulation |
| Bank transaction feed | Daily to real-time | Misses income disruption |
| Device/fraud signal | Real-time | Misses account takeover mid-session |
| Card network settlement | Hours (estimate) | Misses recent large purchases |
When a model treats a monthly bureau pull and a real-time fraud score as equally "current," it creates a silent mismatch. The bureau data anchors a risk decision to a three-to-four-week-old snapshot of the world, while the fraud engine reacts to the last five seconds. Products that blend these without accounting for "data age" tend to over-trust the freshest signal and under-trust the stale one, or vice versa, depending on model design.
Data isn't free, and pricing structures shape product economics.
The strategic issue is lock-in. Switching bureau or aggregator vendors mid-product often means re-underwriting your entire model, because score distributions and data schemas differ across providers. This is why due diligence on a fintech startup should always ask: which vendors, what refresh cadence, and what happens if that vendor changes pricing or is acquired (as happened when Visa attempted to acquire Plaid in 2020, a deal blocked by the US Department of Justice on antitrust grounds).
Once you know the sources, the next fluency layer is measuring their quality. Four metrics recur across fintech data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition →:
1. Freshness (data latency). Time between when an event occurred and when it's reflected in your system. Measured in minutes, hours, or days depending on source.
2. Completeness. Percentage of expected fields populated. A bank aggregator feed with 15% of transactions missing merchant category codes creates blind spots in spend-based underwriting.
3. Match rate. In identity and fraud contexts, the percentage of records successfully matched across two data sources (for example, matching a bureau file to a bank account under the same identity). Low match rates inflate false declines.
4. Drift. Change in a data source's statistical distribution over time. A card network's merchant category code taxonomy update, or a bureau's scoring model refresh (FICO periodically releases new score versions), can silently shift model inputs without anyone touching the model itself.
A simple worked example: if a lender pulls 100,000 bureau reports a month and 4,000 fail to match to an existing internal customer record, the match rate is 96%. If that drops to 90% after a vendor changes its file format, that 6-point drop could mean thousands of applicants misrouted to manual review, a real operational cost, not just a data hygiene footnote.
For a deeper primer on 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 → dimensions generally, the DAMA data quality framework is a widely used, freely referenced standard in data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → circles.
Knowledge check
1. The lending app example in the lesson illustrates a failure mode where the risk model itself was sound but the outcome was wrong anyway. What was the actual root cause?
2. Why do credit bureau files typically refresh on a roughly monthly cycle rather than in real time?
3. A fintech company wants near-real-time visibility into a customer's checking account balance to power an instant affordability check. Based on the lesson, which factor most determines whether this is actually achievable in real time?
4. Select ALL correct answers about why the fintech data landscape differs between the US and Europe as described in the lesson.
Select all the correct answers.
5. Select ALL correct answers that accurately describe card network data as covered in the lesson.
Select all the correct answers.
Regulation shapes what data can be used and how fresh it must be kept.
Governance teams typically track a "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 →" mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition →: where did this field originate, what transformations happened to it, and who is accountable if it's wrong. Without lineage, a stale or corrupted upstream feed can propagate into a credit decision with no clear audit trail, a serious problem under both FCRA adverse action requirements and GDPR's "right to explanation" provisions.
Teams often build lightweight monitors comparing expected versus actual refresh timing. A minimal pseudocode check:
# Flag any data source that hasn't refreshed within its SLA window
for source in data_sources:
hours_since_update = now() - source.last_updated
if hours_since_update > source.sla_hours:
alert(f"{source.name} is stale: {hours_since_update}h overdue")This kind of check, run daily across bureau feeds, aggregator syncs, and fraud signals, is a basic but essential governance control that many fintech incidents trace back to not having.
🎬 [VIDEO: "How Credit Bureaus Work" - youtube.com - search for consumer-finance or Khan-Academy-style explainers covering how bureaus collect, score, and refresh credit data]