For years, the institutions that allow companies to connect to financial networks have been buckling under their own weight.
Banking-as-a-service (BaaS) is one of the main models institutions typically rely on to offer financial services, such as accounts, cards and payments, to their customers.
BaaS is traditionally offered to non-financial institutions to ‘rent’ the licence and infrastructure of a host bank behind the scenes. The host bank then onboards and owns relationships with the institution’s end users.
But, when banks started to onboard specifically financial institutions they applied the same approach of onboarding its end users without knowing enough about them or the risks they could bring.
This raises the question of whether the standard banking partnership model is broken or simply poorly designed.
Sifted sat down with Olegs Cernisevs, chief technology officer at fintech company Blackcat and a chief architect of the infrastructure behind Papaya, to explore how the correspondent service is redesigning the approach to financial infrastructure.
Rather than vetting millions of individual end-users, Papaya vets partners themselves. That’s who they onboard, perform due diligence on and monitor as a client. The partner’s end-users remain their clients, not Papaya’s.
Do you believe the correspondent banking model is fundamentally broken or has it just been poorly implemented?
The market itself is not broken and the demand for correspondent services is growing.
It was never intended as a model for one financial institution to serve another.
BaaS was designed to give non-financial companies like retailers, marketplaces and SaaS platforms access to banking infrastructure; it was never intended as a model for one financial institution to serve another. But when the industry needed a framework for correspondent relationships, BaaS was the closest thing available.
You end up being legally responsible for monitoring customers you’ve never met, whose behaviour you can’t observe directly and whose risk profile you’re reconstructing from second-hand data.
In a typical BaaS setup today, where and why does the model start to fall apart?
The provider — usually a bank or a licensed institution — is required to treat every end-user of its client as its own customer. But in practice, the provider has no direct relationship with those end-users. It doesn’t control the product interface, it doesn’t handle customer support, it doesn’t see behavioural patterns in real time.
Regulators began to ask: if these are your customers, where is your oversight? We’ve seen this play out across Europe, and institutions that offered correspondent or BaaS programmes have either restricted intake dramatically or exited the market altogether. Not because the demand disappeared, but because the compliance architecture made it unsustainable.
Papaya takes a different approach by onboarding financial institutions rather than end-users. Can you share the thinking behind this?
The difference is in how we use it: it feeds our monitoring and risk-scoring layer.
Our compliance obligations are focused where we actually have control and visibility — on the institution itself, its governance, its risk profile and its transaction patterns.
We still collect granular data on end-users through API integration. We receive the same identity and transaction information that a BaaS provider would. The difference is in how we use it: it feeds our monitoring and risk-scoring layer, but it doesn’t create a client relationship. We use it as intelligence, not as onboarding.
How does this model change the distribution of responsibility between platform providers and financial institutions?
The financial institution retains full responsibility for its own clients, their ongoing due diligence and compliance. Our responsibility is concentrated on the institution itself: is it properly licensed, is its compliance framework sound and are its transaction patterns consistent with its stated business?
The result is that compliance is more effective, because no one is pretending to oversee something they structurally cannot.
What problems does this solve that legacy models couldn’t?
First, it eliminates the phantom-client problem. In legacy BaaS, the provider accumulates clients on paper that it cannot serve or monitor in practice.
Second, it resolves the scalability paradox. Under BaaS, every new end-user your client onboards increases your compliance burden, which means growth becomes a liability. In our model, the compliance load scales with the number of institutional relationships, not with their customer base.
Third, it provides clarity for the regulator. One of the recurring problems with BaaS was that regulators couldn’t clearly determine where one institution’s responsibility ended and another’s began.
Is it possible to reduce regulatory burden without reducing control?
Yes, but if you redefine what ‘burden’ means. The burden in legacy models wasn’t created by regulation itself but by choosing the wrong instrument. When you make someone else’s clients your own, you import all the obligations that come with that status.
By keeping the relationship at the institutional level, we don’t trigger the full suite of end-user obligations. We build a data layer that gives us visibility into what’s happening beneath the surface. We receive client identity data, screen transactions and run risk-scoring via API.
How does this new approach change access for smaller financial institutions?
For a smaller institution entering the EU market, this creates a serious infrastructure gap. You can obtain a licence and build a product, but you cannot connect to the payment rails that your business depends on.
It reopens a market that was closing. Over the past several years, many electronic payment rails (EMIs), payment institutions and fintech companies have found it increasingly difficult to secure correspondent access to SEPA. The banks and larger institutions that used to provide these services have either pulled back or imposed prohibitive conditions precisely because of the compliance issues we’ve been discussing.
For a smaller institution entering the EU market, this creates a serious infrastructure gap. You can obtain a licence and build a product, but you cannot connect to the payment rails that your business depends on. That’s the gap Papaya fills. We provide SEPA Credit Transfer and SEPA access through our direct participation with virtual IBANs, API integration and embedded compliance screening.
What concerns do regulators typically raise about new models like this and how do you address them?
The first concern is always: are you just another institution that doesn’t understand the risks? Regulators have seen a cycle — a new provider enters the correspondent space, grows quickly and then discovers it can’t manage the compliance load it has taken on. So when we describe our model, the initial reaction is often scepticism.
The second concern is data: do you have enough information to detect risk if the end-users aren’t your clients? We collect the same data (identity, transaction history, source of funds) through API but we use it for monitoring and risk assessment.
About Blackcat: Blackcat is a European fintech platform that combines everyday financial services — EUR IBAN accounts, SEPA transfers, cards, free internal account-to-account money transfers, cashback and bonuses — with integrated cryptocurrency functionality in a single multi-wallet application. Fiat services are powered by Papaya Ltd, an Electronic Money Institution authorised and regulated by the Malta Financial Services Authority and a direct SEPA participant. Registration number C55146. Client funds are safeguarded in accordance with applicable legislation. Funds held in e-money accounts are not covered by the Depositor Compensation Scheme. You can get more information about terms and conditions on the website blackcat.app The bonus payment is a part of the loyalty program provided by Baltic Technology Solutions OU. Detailed terms and conditions can be found here. An integrated crypto exchange and custodial crypto wallets are provided by MANERIO Sp. z o.o. You can find more information at maner.io
About Papaya Ltd: Papaya Ltd. is a financial institution registered and headquartered in Malta. As an Electronic Money Institution (EMI) regulated by the Malta Financial Services Authority (MFSA), Papaya Ltd. provides digital payment infrastructure services including Mastercard payment cards and IBAN accounts for individuals and businesses, a PSD2-compliant solution enabling SEPA transfers, and offers co-branded and white-label mobile and online payment solutions. One of the first EMIs in Europe to secure direct access to SEPA, including both SEPA Credit Transfers (SCT) and SEPA Instant (SCT Inst). Papaya Ltd. also acts as a correspondent institution, providing regulated access to the SEPA network for other financial institutions without their own direct SEPA membership. The company also delivers PSD2-compliant API for fintech solutions as AISP and PISP, automated digital Know Your Customer (KYC) solutions, and personal and business International Bank Account Numbers (IBANs).