What BaaS means in an EMI context
Banking-as-a-Service, usually shortened to BaaS, is an industry term for regulated financial capabilities made available to another business through technology and an operating agreement. A fintech may use those capabilities inside its own customer journey instead of building every regulated function from the ground up.
When the regulated provider is an Electronic Money Institution (EMI), the underlying offer should be described accurately. The provider may issue electronic money and provide the payment services permitted by its authorisation. It is not lending out a banking licence, and an e-money payment account is not the same as a bank deposit account.
That distinction matters in marketing, contracts and customer communications. Customers should be able to understand which entity provides the regulated service, which entity operates the interface and where to go for support or a complaint.
The building blocks of a BaaS partnership
A BaaS programme can combine technical connectivity with regulated operations. The exact scope depends on the customer type, jurisdictions, currencies and use case, but a typical design may include:
Customer onboarding flows that collect the information required for KYC or KYB checks.
E-money or payment accounts, account identifiers and payment initiation within the provider’s authorised scope.
Payment rails such as eligible SEPA services, plus reconciliation and transaction reporting.
Screening, transaction monitoring, case handling and escalation processes.
APIs or other technical connections, with authentication, permissions, resilience and change controls.
Customer support, complaints and incident-management responsibilities divided clearly between the parties.
A useful discovery process starts with the intended customer journey, not an API list. The parties should map every step from application and verification to funding, payment execution, account restriction and closure. Each step needs a named owner, a service level and an escalation route.
What remains with the regulated provider
A partner can perform agreed activities, but the regulated provider remains accountable for the obligations that apply to its authorised services. Outsourcing or white-labelling does not make those responsibilities disappear. The provider must retain effective oversight, access to information, audit rights and the ability to act when a control fails.
In practice, that means the EMI must approve the programme’s scope and risk appetite, decide which customers and activities are eligible, and maintain appropriate safeguards for customer funds. It must also be able to monitor performance and terminate or change the arrangement without undermining service continuity or regulatory compliance.
The fintech still has substantial duties. It must use approved wording, follow the agreed onboarding and servicing procedures, protect customer data and credentials, escalate alerts and complaints, and avoid presenting itself as the licensed provider. Contractual clarity is essential, but day-to-day controls determine whether the model works safely.
Questions to settle before integration
Before technical work begins, both parties should agree the answers to a short set of practical questions:
Who is the target customer, and which countries, industries and transaction patterns are in scope?
Which entity contracts with the end customer and how will the regulated provider be disclosed?
Who performs each onboarding check, who makes the acceptance decision and who handles refresh reviews?
Which payment capabilities are available at launch, and which are only planned?
How will funds, fees, reversals, rejected payments and reconciliation exceptions be handled?
What are the incident, complaint, data-protection and business-continuity procedures?
Which reports, audit evidence and performance measures will the provider receive?
These decisions also shape the delivery timeline. A programme with a narrow customer segment and payment scope is generally easier to assess and control than one covering many countries, currencies and higher-risk use cases from day one.
How Zolvat approaches partner-led services
Zolvat is developing partner-led models around e-money accounts, payments and related operational controls. Any BaaS arrangement would be designed within Zolvat’s authorised scope and would remain subject to due diligence, risk assessment, contractual agreement, technical readiness and any required regulatory steps.
The correct starting point is a defined use case: who the customers are, what money flows are expected, which services they need and how the partner will operate them. From there, Zolvat can assess whether the model is eligible and identify the regulatory, operational and technical work required.
BaaS is most valuable when it creates a simpler customer experience without making accountability harder to see. Clear roles, accurate disclosures and disciplined oversight are not obstacles to a launch; they are what make a sustainable launch possible.
Frequently asked questions
No. A partner does not acquire or borrow the regulated provider’s authorisation. The regulated service remains subject to the provider’s permissions and oversight.
No. Technology can support compliant processes, but customer due diligence, monitoring, governance and evidence still require defined responsibilities and controls.
