Most identity checks stop at the login succeeding. That is one fact out of several the connection could answer.
Not "can you connect to a bank". It is what do you do with the connection once you have it, for identity, for income, or both. One connection answers three different questions, and most buyers only ever ask the first one.
PSD2-rail access to account data, used three ways from one connection: as an identification method (the bank already verified this person; reuse that), as a data product (ownership, income pattern, behaviour) for cases that need more than identity, and as Verification of Payee, confirming the named account holder before a payment goes out. VOP runs today and is built into Poros's own account checks.
Where a login on its own is not sufficient assurance, a challenge deposit is the stronger route: a small reference transaction from the account in question, which demonstrates control of the account rather than knowledge of its credentials. The German-speaking markets know it as a Referenztransaktion. It is integrated and can be switched on per market. It is not on by default, because it carries an operational cost that only some risk policies need to pay.
The same rail also moves money. Under PSD2 an account connection can be used to initiate a payment as well as to read one: the customer approves it inside their own bank, and the funds move from account to account rather than over a card. That is why the challenge deposit above is possible at all, and it means a business already connecting accounts for verification can accept payment over the connection it has built. Payment initiation uses the same consented bank connection to move funds directly from account to account, alongside verification and account-data uses.
The connection itself is one canonical integration. Which of these answers you take from it is a configuration, not a second piece of work.
A login is not an identity check, a data pull or a payee confirmation. It is a credential success. What you ask the connection afterwards is the actual product, and most of the market stops at the credential success and calls it done.
| Use case | What it proves | Where it breaks |
|---|---|---|
| Identification | The bank already verified this person before it opened the account. Reuse that instead of asking for a document again. | On joint, shared and business accounts. A successful login proves somebody in the household or the company has access, not which specific person is applying. |
| Data: ownership, income, behaviour | More than a yes: who the account belongs to, whether income arrives regularly, how the account behaves, for the cases that need more than an identity. | Where the connected account is not the account the decision concerns. A secondary or recently opened account carries too little history to say anything, and it still connects perfectly well. |
| Verification of Payee | That the named account holder matches the account about to be paid, checked before the payment goes out. | By design rather than by failure. It informs a payment decision, it does not block one: after a mismatch warning the payer can still proceed. |
This table is what the connection can prove. Payment initiation uses the same rail for a different job: moving money rather than answering an identity, account-data or payee question. Buying the connection once and using it several ways is the efficient design. Several separate integrations for the same rail is the one most stacks end up with.
Open banking across 21 countries, with 80 percent bank coverage and 567 million accounts.
A bank login treated as a full identity check, when the account is joint or shared, attributes the check to the wrong person.
Identification only, data only, or both, set per use case.
How much you get out of one connection is a commercial decision before it is a technical one. Taken as a login it removes a document upload from the flow. Taken as a data product it also tells you whether the income on the application is real and whether this customer can carry what they are applying for, which is the difference between an onboarding check and an underwriting one.
The customer authenticated at their own bank, and that bank had already verified them to open the account. The file needs to record that for what it is: assurance inherited from a regulated institution, with the date it was obtained and the scope the customer consented to. Consent is scoped and it expires, and a file that does not carry those two facts cannot show later what it was entitled to see.
The failure modes are ordinary and they decide whether this works in production. A bank that is slow or briefly unavailable. A customer who abandons on their own bank's screen. An account that connects perfectly and is not the account the decision is about. A flow that reads any of those as a red flag punishes ordinary customers, so the fallback route deserves as much attention as the connection.
Written once, used as identification in KYC and as a risk signal in Risk Intelligence, one canonical integration either way.