CCD2 Compliance Starts with Data, Not Policy

Most of the discussions around Europe’s second Consumer Credit Directive (CCD2) right now are focused on the policy. How lenders should structure their affordability assessments, what disclosures they need to give consumers, and which credit products (namely BNPL) are newly brought into scope. But very little attention is being paid to the infrastructure underneath those assessments. Because CCD2 compliance ultimately depends on something even less glamorous than policy: obtaining reliable financial data from European banks at scale.

Complying with CCD2's affordability requirements doesn't just mean updating your credit policy. It means reliably accessing the right financial data across the European markets where you operate. And that part (the infrastructure part) is where most of the real work lives.

What CCD2 actually demands from your data layer

The revised Consumer Credit Directive raises the evidentiary bar for creditworthiness assessments. Lenders, including BNPL providers and short-term credit products that previously sat outside the regulatory perimeter, must now demonstrate that a credit decision was grounded in documented, traceable evidence of a consumer's income, expenditure, and existing liabilities.

We are obviously biased, but open banking data is the clearest answer. When a lender pulls bank account data at the point of application, they are seeing everything in real-time, current income, recurring expenses, overdraft behaviour, and existing payment commitments, not a snapshot from weeks or months ago. That real-time view is exactly what a CCD2-compliant affordability assessment should be built on. If you need current, verifiable financial data, PSD2-accessed bank account data is hard to beat.

In that context, CCD2 and PSD2 are two sides of the same coin. PSD2 created the mechanism to access real-time bank data with customer consent. CCD2 creates the obligation to use exactly that kind of data to prove affordability.

It's not just theoretical either. In an interview with UC last year, they mentioned that a client combining UC's conventional credit data with open banking data saw up to 30% lower credit risk in its portfolio, thanks to improved assessment accuracy and reduced uncertainty. That kind of outcome isn't just commercially attractive, it's exactly the traceable documentation of repayment capacity that CCD2 is asking for.

What's less obvious is how fragile that data layer can be if you haven't thought carefully about what's underneath it.

The infrastructure assumption hiding inside every CCD2 compliance plan

When lenders say they'll use open banking data for CCD2 compliance, they're usually thinking about the use case: a consent flow, a bank connection, transaction data feeding into an affordability model. That picture is accurate. It's also incomplete. What they're less focused on is the step before all of that: reliably getting the data out of the bank in the first place. 

PSD2 created the right of access to bank data. What it never really created was consistency. Two banks in the same European country, responding to the same request, can return data in completely different shapes. Field names differ. Authentication flows differ. The same piece of information can appear in entirely different places depending on the bank's core banking system. And banks don't always announce when something changes, which means an affordability model can quietly stop receiving data overnight, with no error, no alert, just subtly wrong output feeding into a credit decision.

The inconsistencies aren't abstract. Take address data: one bank labels it “address”, another uses “postal address”, and a third uses “creditor address”. None of them is wrong exactly; they're just different. Or take IBANs. The format is universally understood, but how a bank delivers it varies considerably. Some return both an IBAN and a domestic BBAN simultaneously, with no clear indication of which to use. Others place the IBAN in a general “creditor account” or “debtor account” field rather than the dedicated identifier field where it's supposed to live. Multiply that across thousands of banks and thirty markets, and you have a data normalisation problem that sits entirely below the level most CCD2 planning addresses.

This isn't a flaw in any individual bank's implementation. It's the reality of a regulatory framework that prioritised opening up access over enforcing consistency.

For a lender building CCD2 compliance on top of open banking data, that inconsistency has direct consequences. Your audit trail is only as good as your data. If an income figure comes from a field that was incorrectly mapped, or a fetch that silently failed, or a bank whose response format quietly shifted, your documentation of repayment capacity starts to have gaps. The compliance case unravels from the data layer up.

Proportionality cuts both ways

CCD2 introduces explicit proportionality. Smaller, shorter-term credits don't require the same depth of assessment as large consumer loans. In Sweden, the proposed national implementation appears to narrow this flexibility, pushing even smaller BNPL assessments toward more standardised documentation requirements.

That direction became more concrete very recently. On 20 May, Finansinspektionen proposed new regulations and general guidelines for consumer credit, with a response deadline of 18 June 2026 and everything proposed to come into effect on 20 November. Notably, FI is proposing clarifications on which information should form the basis of a credit assessment and how it should be collected and verified, language that points squarely at traceable data. The proposals also extend supervision to so-called subsidiary credit providers: companies for whom credit is not their primary business, including many of the embedded finance and BNPL playersthat the directive was always intended to reach. For those companies, this may be their first meaningful encounter with FI oversight.

Proportionality in the regulatory sense is about calibrating the assessment to the risk profile of each loan. But there's a practical dimension too. Proportionate compliance means your data infrastructure should be efficient enough that thorough affordability checks don't introduce friction that kills conversion. Compliance and conversion optimisation must be pushing towards the same goal. 

This is where API-based data access changes the picture entirely. Pulling financial data directly from a bank account via API takes seconds and returns structured, verified data automatically. The alternative is asking applicants to upload bank statements or transaction exports manually. It is slower, more error-prone, and places the burden on the consumer at exactly the moment you most need them to complete the journey. In fact, the difference in outcome is significant. Data shows conversion rates of 65% to 70% with open banking, falling to between 30% and 50% when customers are asked to share data manually. That's not a marginal difference. Requiring manual document sharing means losing up to half your applicants before they can even complete the process.

What good infrastructure actually looks like

A reliable open banking data layer for CCD2 compliance needs a few things to work at once. Consistent data structures across markets are an obvious starting point. An income figure returned from a Danish bank and a Polish bank should arrive in the same structure, mapped to the same fields, ready to feed the same affordability model without manual transformation at the application layer. This is what harmonisation means in practice: not a nice-to-have, but the precondition for any scalable compliance approach.

Then there's monitoring. Banks update their APIs constantly. When they do, you need to know as soon as possible, not when a loan application fails or an auditor asks questions. This requires active monitoring of live integrations, not just initial testing at the point of connection.

And underneath all of that sits traceability. CCD2 compliance requires documented evidence of the assessment process. That means knowing not just what data you had, but where it came from, when it was fetched. Your audit trail needs to reach down into the data layer.

None of this is achievable if you're stitching together bank integrations on a market-by-market basis. The overhead compounds too quickly. The maintenance burden grows with every market you enter, every bank that updates its API, every edge case that surfaces in production.

The part that tends to get skipped in CCD2 discussions

Most of the CCD2 commentary focuses on what changes at the policy level: which products are in scope, what disclosures are required, and how affordability assessments should be structured. That's all important.

But CCD2 compliance is ultimately executed at the infrastructure level. A well-designed credit policy running on unreliable data infrastructure isn't compliant. It just looks like it might be, until it doesn't.

For lenders and BNPL providers building toward November 2026, the question worth asking isn't only "what does our credit model look like under CCD2?" It's "what does our data layer look like, and can it support what the model needs to do?"

Open banking data is the right answer to CCD2's affordability requirements. Getting auditable access to that data across European markets is an infrastructure problem, and one that's worth solving properly before it surfaces in a compliance review.

Open banking data is the right answer to CCD2's affordability requirements. Getting consistent, reliable, auditable access to that data across European markets is an infrastructure problem, and one that's worth solving properly before it surfaces in a compliance review. That means having someone monitoring live bank integrations across Europe on your behalf, so that when a bank updates its API at midnight, you find out before your affordability model does.

Enable Banking provides an open banking infrastructure connecting over 2,700 banks across 30 European markets through a single API. Our harmonised data layer is built to support exactly the kind of reliable, traceable data access that CCD2 compliance requires.