Banking-as-a-Service · Use case
Add SEPA, Faster Payments or SWIFT payment rails
Short answer
If your product has to send or receive bank transfers, a BaaS provider gives you scheme access through its licence, plus settlement and reconciliation. Choose rails by where your customers and their counterparties are, and ask whether access is direct or through a correspondent.
What this use case is
Domestic and cross-border transfers — euro, sterling and international — built into your product through one API.
Who builds this
What your customer sees
- 1Enters or selects a payee
- 2Sees the payee name checked
- 3Confirms
- 4Receives status updates
- 5Sees the payment on the statement
How Banking-as-a-Service solves it
Payment initiated through the API
Payment initiated through the API
Validation, sanctions screening and payee verification
Validation, sanctions screening and payee verification
Submission to the scheme, directly or via a correspondent
Submission to the scheme, directly or via a correspondent
Settlement and status updates by webhook
Settlement and status updates by webhook
Returns, rejects and recalls handled
Returns, rejects and recalls handled
Reconciliation data available for your ledger
Reconciliation data available for your ledger
Want to have
- SEPA Credit Transfer and SEPA Instant for the EU
- Faster Payments, and BACS or CHAPS where needed, for the UK
- SWIFT with clear correspondent coverage
- Payee verification
- Sanctions screening
- Status tracking
- Returns and recalls
- Bulk payments
- Published cut-off times
Optional
- SEPA Direct Debit collection
- Request-to-pay
- Local rails outside the EU and UK
Design decisions
Scheme access
control, cost and speed versus availability
Instant by default
customer expectation versus cost and fraud exposure
SWIFT charging
who pays intermediary fees and how predictable the received amount is
What to put in your RFP
Rails
- schemes, currencies and corridors required
Access
- direct or indirect
- instant availability
Controls
- sanctions screening, payee verification, limits
Operations
- returns, recalls, investigations, cut-offs, holidays
Data
- status webhooks, reconciliation files and fields
Commercials
- per-rail pricing, SWIFT fees, FX where relevant
How to evaluate providers for this use case
- 1Scheme coverage matching your flows
- 2Instant availability
- 3Transparency of SWIFT fees
- 4Operational support for failed payments
- 5Quality of reconciliation data
Pitfalls
- Assuming instant coverage everywhere
- Underestimating the operational load of failed and returned payments
- Opaque intermediary fees on SWIFT
- Ignoring cut-off times and bank holidays
What providers will ask you
- Payment corridors and currencies
- Expected volumes by rail
- Who handles payment investigations
Other Finlane categories that cover parts of this
This use case is solved mainly with Banking-as-a-Service. These categories cover specific parts of it and can be tendered alongside it.
Frequently asked questions
Questions for this use case are covered in the category guide.
Other Banking-as-a-Service use cases
Spin up a consumer or SMB banking product with named IBANs, deposits and everyday payments — without holding a banking licence yourself.
Embed accounts in a vertical SaaSGive your customers a segregated account inside your platform (invoicing, payroll, marketplace payouts) with the BaaS provider handling KYC, safeguarding and ledgering.
Operate a marketplace payout flowHold buyer funds, split them between sellers, and pay out on schedule — with the compliance and safeguarding perimeter owned by the BaaS partner.
Offer multi-currency accounts and FXGive business or consumer customers accounts in EUR, GBP, USD and beyond, with transparent FX and international transfers.
White-label a banking product for enterpriseStand up a co-branded banking experience for a bank, telco or retailer — with the BaaS provider handling core banking, statements and regulatory reporting.