The deadline for mandatory consumer-credit assessment under CCD2 is closing in fast. Picking the right open banking data provider now decides whose data your scoring model leans on. The most reliable way to find out is a proof of concept run on your own customers.
Why the choice of open banking data provider matters
Choosing an open banking data provider is slowly becoming a key decision. From 20 November 2026 the EU requires lenders to assess consumer creditworthiness in a way that is consistent, auditable, and grounded in verified data. What that means in practice depends on where you sit in the market.
If you're a BNPL provider, creditworthiness checks will likely be entirely new to you, or they'll force a major overhaul of how you operate today. If you're a traditional consumer lender, the exact impact depends on your market, but in most cases the pressure on how you verify an applicant's income and expenses will only grow. Self-declared figures won't cut it.
For the full scope of the directive, see our breakdown of what CCD2 changes for lenders and BNPL.
For practically every lender it comes down to the same thing: either the applicant submits bank statements (PDF, scan, or photo), or they grant direct access to their account through a PSD2-based open banking connection. Each route has its pitfalls. Either way, what decides the outcome is data quality and the ability to interpret it correctly.
Why open banking data is unreliable, and what to do about it
Open banking data is nowhere near the quality banks are used to. Income and expense signals aren’t always legible at first glance. Take peer-to-peer payments: regular rent paid to a friend may carry no description that hints at what it actually is.
For more on the mechanics, see how payment data enrichment works in open banking.
Predicting algorithmically that such a payment recurs, and then classifying it, is precisely what matters. This is where third parties offering data enrichment, or AISP connectivity itself, come in. Their capabilities vary widely, and picking the wrong partner can have serious consequences.
An example. A model flags an incoming payment of EUR 690 as employment income. In reality it’s a one-off refund of a rental deposit on a flat the applicant has just left to move back in with their parents. That income won’t recur. And CCD2 expects you to tell the difference reliably.
Not knowing is bad. A wrong signal you’re betting on in your scoring model is worse.
Proof of concept: the strongest tool for choosing a vendor
So how do you choose between data enrichment providers? And how do you keep checking that you’re still getting the best service on offer? The most reliable approach, time and again, is a proof of concept (PoC): comparing solutions on a sample of your real customers’ data.
Ground rules for a sound PoC
For a PoC to produce conclusions you can act on, it has to meet a few conditions:
- Every vendor under review (including any in-house model) works with the same data sample in the same format. No exceptions.
- The data is structured by individual customer, not as isolated transactions torn out of context. The whole point is to assess specific applicants.
- The sample is robust enough. This is the floor for a meaningful comparison: ideally at least 20 customers and 20,000 transactions, with variety mattering just as much, so mix applicants you approved with those you rejected. Larger lenders can and usually should test on far bigger samples: hundreds of customers and millions of transactions give a more realistic read on both coverage and accuracy, while sharply cutting the chance that a vendor hand-polishes the results.
- Include the edge cases you’re unhappy with today. For instance, where your current model can’t reliably identify P2P rent payments, or a type of social benefit where the paying institution’s account or its description keeps changing.
PoC duration and guarding against skewed results
A PoC should run for a fixed period, the same for everyone involved. Setting it at roughly five working days sharply limits the risk of vendors hand-improving results (so-called boosting), where specific samples get extra care instead of routine processing.
What data the vendors work with
The open banking data a lender pulls through an AISP connection isn’t always structured the same way; the specific field names differ from bank to bank. In practice, though, you work with four basic parameters that should always be present:
- Transaction timestamp is the date and time the transaction took place. Without it you can’t reconstruct timing patterns or judge whether income recurs.
- Amount and direction tells you how much money moved and which way: incoming (credit) or outgoing (debit). Direction may be encoded as a separate field or as the sign of the amount (+ / −).
- Counterparty identification is the account number or name of the counterparty (payer or payee). It lets you spot recurring counterparties: employers, landlords, lenders.
- Payment description is a message to the payee or an auto-generated text description of the transaction. It tends to be inconsistent and truncated, but it still carries valuable signals: “rent”, “salary”, “benefit”, even stray initials in the payment text can change a classification entirely.
The lender doesn’t get this data from the consumer. The consumer only grants consent, and the lender pulls the data itself through the AISP connection. What matters is handing every vendor under test the same set of attributes in the same structure. If the inputs differ, the results can’t be compared.
If the data from the PSD2 connection is less complete (missing payment descriptions, inconsistent or truncated counterparty identification), that will show in the results. Weaker coverage or accuracy in that case isn’t necessarily the vendor’s fault. The key is that the limitation hits every tested party equally: if one vendor lags well behind the rest on identical inputs, that’s a different matter. The reverse holds too: anything beyond the four basic attributes (a bank-assigned category, currency code, counterparty account identifier) can improve classification. It pays to hand over everything you have.
What exactly to evaluate
Watch out for one tempting-looking metric: the number of transactions that got some kind of flag (coverage). On its own it tells you nothing. What counts is three dimensions taken together:
- Coverage tells you how many transactions received a flag. On its own, it says nothing.
- Accuracy tells you whether the assigned flag is correct. Income labelled as employment income, an expense recognised as a loan repayment. The whole decision essentially hinges on this comparison.
- Classification depth shows how granularly a model can categorise. Knowing something is an expense isn’t enough. For CCD2 you need to know whether it’s rent, a repayment on another loan, a recurring utility payment, or a one-off spend on entertainment. A model that returns “other” instead of a specific category is of limited use for assessing creditworthiness.
Depending on your business model and regulatory context, you’ll weight different outputs:
- Identifying and predicting income (key for traditional lenders and for calculating disposable balance).
- Segmenting expenses into categories such as housing, utilities and services, groceries, entertainment, or repayments on existing loans (relevant above all for BNPL providers).
- Telling one-off income apart from recurring income (decisive for predicting an applicant’s future financial situation).
Share these criteria with every vendor involved upfront. It saves time on both sides and avoids ending up with results you can’t compare because each vendor measured something slightly different.
How to prepare for a PoC properly
A PoC is only as good as the data it runs on. Before you approach the first prospective vendors, make sure you have transaction records ready in sufficient volume and quality.
A good data sample for a PoC meets three conditions:
- It’s large enough, both in number of customers and number of transactions.
- It’s representative: it covers different applicant profiles, including the edge cases that worry you.
- It reflects your specific problem: whether that’s rejecting creditworthy customers too aggressively, excessive defaults, or simply compliance with the CCD2 framework.
Without a clearly defined problem you want the PoC to solve, you risk results that are interesting but useless for making a decision.
PoC results aren’t just numbers in a table. They tell you who to trust with part of your credit process and who not to. It’s worth doing properly.
