You can get a licence. You can build the product. What you increasingly can't do, if you're a smaller financial institution in Europe, is buy your way onto SEPA. Dr. Olegs Cernisevs, CTO of Blackcat, argues the reason is hiding in plain sight, and that solving it is less complicated than it looks.
A pattern has played out across European payments over the past few years. Electronic money institutions, payment institutions, and smaller fintech firms obtain a licence, build a product, line up customers – and then discover they cannot reach the one thing the whole business depends on: the payment rails. Correspondent access to SEPA, once a routine service to procure, has quietly become one of the hardest things for a new institution to secure.
The usual explanation is that regulation got heavier and the banks grew nervous. That explanation is too easy, and it points at the wrong cause. At its root, the access gap is not a regulatory problem. It is a design problem: the result of stretching one model, Banking-as-a-Service (BaaS), to do a job it was never built for.
A model used for the wrong job
BaaS was designed for a specific purpose: to give non-financial companies – retailers, marketplaces, SaaS platforms – access to financial infrastructure without becoming licensed institutions themselves. A host institution holds the licence and the rails, the partner builds the customer experience on top. For that purpose it works well, and it still does.
The trouble began when the industry needed a way for one regulated institution to serve another and reached for BaaS because it was the closest tool to hand. A framework built for a retailer wiring up checkout was pushed into correspondent relationships between financial institutions. The instrument was wrong from the start, and everything that followed flowed from that single mismatch.
The phantom-client problem
Apply BaaS to a correspondent context and a structural flaw appears at once. The provider is treated, in regulatory terms, as though every end-user of its partner were its own customer. On paper it owns those relationships. In practice, it has none: it does not control the interface those people use, does not handle their support, does not see their behaviour in real time. It is asked to monitor customers it has never met, whose risk it is reconstructing from second-hand data.
Regulators noticed, and asked the obvious question: if these are your customers, where is your oversight? Most providers could not answer it well. Across Europe the response was the same: institutions running correspondent or BaaS programmes restricted intake sharply or left the market altogether.
Onboard the institution, not its customers
The fix is the right instrument. In a correspondent model done properly, you onboard the institution,
not its end-users. The institution is your client: its licensing, its governance, its risk profile, and its transaction patterns are what you perform due diligence on and monitor. Its customers remain its own.
This is not a way of seeing less. We still receive granular end-user data through API integration – the same identity, transaction, and source-of-funds information a BaaS provider would collect. The difference is what that data is for. It feeds a monitoring and risk-scoring layer; it is intelligence, not onboarding. We use it to see what is happening beneath the surface, without pretending customer relationships do not exist. Where a partner is itself a regulated business with its own reporting obligations – a crypto exchange subject to the Travel Rule, for instance – the same integration carries the information each side needs to meet its own requirements.
The principle here is, in essence, old-school correspondent service, where each party is responsible for its own job and no one answers for something they structurally cannot see.
What this resolves
Getting the instrument right fixes all three failures at once: no clients carried on paper that can't be served, a compliance load that scales with institutional relationships rather than their customer base, and a clear line for the regulator between one institution's responsibility and the next. The effect is to reopen a market that was closing.
A financial institution can hold a licence and a finished product and still be stranded without a route to the rails – and direct SEPA participation, with virtual IBANs, API integration, and screening built in, is the bridge across that gap. That is the role Papaya Ltd. plays as a licensed correspondent institution, and the same infrastructure carries our partner consumer product, Blackcat.
About the author
Olegs Cernisevs is CTO of Blackcat and the chief architect of the payment infrastructure behind Papaya Ltd. He has experience in banking and payment services, including at PrivatBank, First Swiss Card, and the Acquiring Committee of the Association of Commercial Banks of Latvia. Olegs has been instrumental in shaping IT projects for various European financial institutions. He holds a master’s degree in international business and management and several certificates in anti-money laundering management. Additionally, Olegs published several scientific papers on fintech-related topics.
About Blackсat
Blackcat is a European fintech brand built around a simple idea: earn, spend, and save, your way. Its services are backed by licences issued to Papaya Ltd, an Electronic Money Institution authorised and regulated by the Malta Financial Services Authority (registration number C55146) and one of the first EMIs in Europe to secure direct access to SEPA, including SEPA Credit Transfers and SEPA Instant. Papaya also acts as a correspondent institution, providing regulated access to the SEPA network for financial institutions without their own direct SEPA membership. Client funds are safeguarded in accordance with applicable legislation. Funds held in e-money accounts are not covered by the Depositor Compensation Scheme.
