The EU's revised Consumer Credit Directive (CCD2 for short) is about to change the rules for consumer lending and BNPL across Europe. By November 2026, lenders will need to prove that borrowers can actually afford what they're signing up for. That puts transaction data at the centre of every credit decision.
But here's the problem most providers aren't talking about: the transaction data they're working with isn't ready for that job.
What is CCD2
CCD2 (Directive (EU) 2023/2225) is the EU's overhaul of its consumer credit framework, replacing the 2008 directive. Member States were required to transpose it into national law by 20 November 2025, with full application from 20 November 2026 - though transposition is still in progress across. A handful of countries (Denmark, Sweden, Finland, the Netherlands) are furthest along; others are still finalising their national implementation.
The key changes: CCD2 widens the regulatory perimeter for consumer credit in both directions. The old €200 lower threshold has been removed, bringing even small-value loans and interest-free instalments into scope. The upper limit has been raised to €100,000. BNPL, deferred debit cards, overdrafts, and leasing with purchase options are all explicitly covered. Under Article 18, lenders must base affordability decisions on verified, factual financial data. Critically, a proportionality principle applies: the depth and rigour of the assessment must match the nature, duration, value, and risk of the credit. A €3,000 short-term loan triggers different requirements than a €50,000 twelve-month facility.
Assessments must be documented, consistent, and auditable. The EBA guidelines on loan origination provide the general framework (requiring that checks capture income, liabilities, and resilience to financial shocks) but national regulators will interpret and adapt these guidelines to their own markets. The practical impact varies: some jurisdictions (such as the Czech Republic, where the CNB already required much of what CCD2 mandates) face a smaller adjustment than others.
Why CCD2 changes the game for BNPL & lenders
Under CCD2, BNPL is explicitly classified as credit. Providers must obtain licensing, conduct full creditworthiness assessments aligned with their national regulator's guidelines, and comply with disclosure obligations - though proportionality is preserved, meaning the requirements scale with the size and risk of the credit being offered.
The burden shifts. It's no longer enough to enable a transaction and manage default risk retroactively. CCD2 requires providers to demonstrate affordability before credit is granted. BNPL services that already use transaction-level data for scoring, like Twisto or Skip Pay, are better positioned, but even for them, data quality remains a key factor.
Compliance costs will increase. Oliver Wyman's analysis suggests providers will need to rethink pricing - raising merchant fees or introducing minimum thresholds. Smaller players may not absorb the costs, accelerating consolidation. Some fintech lenders are pivoting to B2B payment flexibility and SME lending, where CCD2's heaviest obligations don't apply. However, this only works if the lending genuinely serves business purposes - structuring a consumer loan through a shell business entity to avoid CCD2 obligations is not a compliant strategy. The shift signals how significant those obligations have become.
The bottom line: CCD2 moves BNPL from a payments-adjacent convenience into the regulated credit perimeter. For any provider that remains in consumer lending, the data infrastructure behind affordability decisions is a regulatory requirement.
Why transaction data becomes critical
CCD2's requirement for verified financial data makes transaction data the most direct source for a compliant affordability assessment. It reveals income streams (salary, freelance, benefits), recurring expenses (rent, utilities, subscriptions), existing liabilities (loan repayments, credit card debt), and risky financial behaviour (gambling, payday loan usage, overdraft cycling).
The EBA guidelines outline the categories that matter, but local supervisory authorities ultimately decide the priorities for their market. One national regulator may focus heavily on gambling and high-cost credit exposure; another may weigh income stability or overdraft patterns differently. Transaction data is the common input layer that supports all of these approaches - and CCD2 expects lenders to use it.
The problem: transaction data quality
In its raw form, transaction data is far from usable.
Raw transaction descriptions are inconsistent, cryptic, and frequently meaningless to anyone outside the issuing bank's systems. A single coffee chain might appear as "SQ *COSTA COFFEE 1234", "COSTA C LON GB", or "POS PURCHASE 08/04" depending on the bank, the payment processor, and the card network involved. Multiply that across thousands of merchants and millions of transactions, and the scale of the data quality challenge becomes clear.
The core issues include:
Unclear merchant names. Transaction description fields are free-text strings that vary between banks, acquirers, and payment networks. A merchant name is often coded, or buried behind a payment facilitator's identifier like PayPal, Square, and similar processors.
Missing or unreliable categories. Although Merchant Category Codes (MCCs) exist in the payment specification, banks are not required to pass them through in open banking feeds. And even when MCCs are present, they can be misleading: MCC 6012, for example, might indicate a payday lender, a crypto exchange, or an early wage access provider - three very different risk profiles collapsed into one code.
Messy open banking data. Open banking has dramatically expanded access to transaction data, but it has not solved the quality problem. Data arrives in many shapes and formats across banks and jurisdictions. Fee transactions are frequently miscategorised, and there is no standardised enrichment layer built into open banking APIs.
For a deeper look at how payment data enrichment addresses these challenges in open banking, see our article Payment Data Enrichment in Open Banking
Why this is a real risk under CCD2
Under the old regulatory framework, messy transaction data was an operational inconvenience. Under CCD2, it becomes a compliance liability.
The directive requires that creditworthiness assessments be based on "sufficient information" that is accurate, verified, and proportionate to the credit being offered. If the data feeding those assessments is unreliable, the entire decision chain is compromised.
Here's how data quality failures translate into real risk:
Wrong categorisation leads to wrong affordability outcomes. If a gambling transaction is categorised as general retail, or a loan repayment is labelled as a miscellaneous transfer, the lender's affordability model is working with a distorted picture of the consumer's financial behaviour.
Missed income means incorrect scoring. If a consumer's salary is split across multiple irregular deposits, or if freelance income arrives from different payment platforms, a system that can't reliably detect and aggregate income patterns will understate the consumer's earning capacity.
Undetected liabilities create regulatory exposure. If existing debt repayments aren't correctly identified in transaction data, the lender is effectively blind to a portion of the consumer's debt burden.
The cumulative effect is significant. National competent authorities, the ECB, and the EBA all have the power to scrutinise lending decisions, demand remediation, impose fines, and restrict business lines. And because CCD2 requires that decisions be documented and auditable, every data quality shortfall leaves a trail.
From raw data to credit-ready data
Bridging the gap between raw feeds and CCD2-compliant data requires clean merchant identity (resolving a string like ALBERT HEIJN 1628>AMERSFOOR into merchant "Albert Heijn", category "Grocery", tag "Supermarket", verified address), reliable granular categorisation that goes beyond broad MCC buckets, detection of income patterns and recurring committed expenditure, and identification of risk signals like gambling, payday loans, and overdraft cycling.
Without these capabilities, lenders are building compliance-critical models on unreliable inputs.
How Tapix helps
The gap between raw transaction data and credit-ready output exists on a spectrum. At one end sits standard open banking data quality - where the only usable attribute is the transaction description. In the middle sits core banking quality, where MCC codes and structured transaction descriptions provide a better starting point. At the top sits the kind of enrichment that credit decisions actually require.
Tapix operates at the top of that spectrum. Where standard open banking data relies on a single attribute and core banking data adds MCC codes and transaction descriptions, Tapix draws on six distinct data layers: MCC codes, transaction descriptions and account numbers, merchant IDs and POS IDs, verified merchant names, merchant websites, and external data sources including business registers, social networks, and search engines. The result is a cross-validated enrichment that doesn't depend on any single unreliable input.
Tapix's consumer credit framework is built around three detection priorities that map directly to CCD2's affordability assessment requirements:
Income detection. Distinguishing total income from stable employment income. Identifying social benefits, freelance payments, and irregular income streams. Providing the verified, factual income picture that Article 18 of CCD2 demands.
Liabilities and recurring expenses. Identifying loan repayments and existing credit commitments, tax obligations, rent, utilities, and other fixed expenditures. These are the committed obligations that determine the capacity for additional debt.
Risk signal extraction. Flagging gambling transactions, overdraft fees, crypto activity, payday loan usage, and other behavioural indicators that signal financial stress or high-risk patterns.
Tapix's categorisation engine is backed by a cross-validation framework that combines algorithmic error reduction with over 30 human data validators and a continuous feedback loop from end users who flag errors and propose improvements.
CCD2 forces lenders not only to collect transaction data, but to understand it. Tapix makes that possible.
