How does a fintech get IBANs and SEPA/SWIFT access?

You get IBANs by issuing them through an institution that holds a place on the rails - either yourself, as a direct scheme participant with settlement access, or, far more commonly at launch, through a BaaS partner that issues IBANs to you over an API. An IBAN is not a product you switch on; it is an account identifier backed by rail access.

The identifier itself is governed by a standard - ISO 13616 - but the standard only defines the format. What makes an IBAN usable is that it sits at an institution that can receive and send on the payment schemes. That is the part that takes work: the identifier is trivial, the access behind it is not, and the access is a relationship.

This is where the operations view matters. Issuing IBANs at any real volume means your back-office can allocate them, attach each to the right customer and currency, and keep every movement reconciled against the rail. I've seen a team treat the IBAN as the finish line, only to discover the real work started the day the identifiers had to reconcile against the scheme. Advapay's Macrobank handles that as current-accounts and IBAN functionality - multi-IBAN issuance and reconciliation on the same core that runs your ledger, so the identifier and the accounting stay in step.

You reach SEPA for euro payments and SWIFT for cross-border messaging either by becoming a scheme participant with your own settlement arrangements, or by consuming both through a BaaS partner who is already a participant. It is the same direct-vs-partnered choice as IBANs, decided on the same axes - speed, control, and economics. For most fintechs, partnered access wins early, because time-to-product is what matters first.

SEPA covers euro credit transfers and direct debits across its participating countries; settlement ultimately runs through Eurosystem infrastructure such as TARGET2/T2 at the ECB. SWIFT is the messaging layer for cross-border payments in other currencies and corridors. A fintech serving European customers usually needs SEPA from day one and adds SWIFT reach as its cross-border use cases grow. The difference between the two rails is laid out in Advapay's SWIFT vs SEPA explainer.

Direct participation gives the best long-run economics and full control, but it is slow and resource-heavy to establish and maintain. Partnered access via BaaS converts that into a single integration and a variable cost - which is why most launch-stage teams I work with start there and take a rail direct later.

SWIFT Alliance Lite 2 is SWIFT's cloud-based connectivity option - a lighter way to connect to the SWIFT network without operating heavy on-premise infrastructure. That makes it a practical route for a fintech that needs its own SWIFT connection but does not want to stand up and run full in-house SWIFT plumbing. It sits between "fully outsourced to a partner" and "fully self-operated."

The reason connectivity options matter is that "reaching SWIFT" is not one thing. You can consume SWIFT entirely through a partner, run a cloud-based connection like Alliance Lite 2 where you hold more of the relationship, or operate full infrastructure at the heavy end. Each step trades operational burden for control, and the right point depends on your volumes, your team, and how much of the messaging relationship you actually want to own.

For most launch-stage businesses, the honest answer is usually to start through a partner and revisit a more direct connection once cross-border volume justifies the lift. One payments firm I worked with was ready to stand up its own SWIFT infrastructure at launch; a year in, its cross-border volume still didn't come close to justifying it, and the partnered route had cost them nothing in credibility. The value of working with a provider that supports the whole range - from partnered access to a cloud connection - is that you can move along it without re-architecting each time.

The back-office is where IBAN and rail access becomes a working operation. It has to issue and manage IBANs at scale, route payments to the right rail, reconcile every inbound and outbound movement against the scheme, and produce the reporting a supervisor expects - all without the books and the product disagreeing. This is the unglamorous core of banking access, and it is where the partnerships story meets the platform.

Multi-IBAN issuance means allocating identifiers across customers and currencies and keeping each tied to the correct ledger account. Reconciliation means matching what the rail says happened against what your core recorded - daily, automatically, with breaks flagged for a human. Macrobank does this on one core, so payments and transfers post straight to the same ledger that issued the IBAN, and reporting reads from a single source of truth.

It is also the sharp difference from the licensing-context view of banking access. The Licensing Playbook banking-access chapter explains whether and how to secure access as part of a launch plan *(cross-link: Playbook "Banking Access & IBANs" - CMS to link once live)*. This piece is about the operational machinery - issuance, routing, reconciliation, connectivity - that makes the access run once you have it.

Advapay delivers IBANs and SEPA/SWIFT access by combining its banking-as-a-service hub and partner network with the Macrobank back-office. A fintech gets rail access through partners who already have it, plus the multi-IBAN issuance, routing, and reconciliation to run it - all on one platform. That is the difference between holding a license and being able to move money on day one.

Because the access is wired into Macrobank, IBAN issuance, payments, FX, and reporting sit on the same core rather than being stitched across disconnected vendors. Through the marketplace of partners and integrations, teams reach the rails without negotiating every relationship from zero, and add or diversify providers as they scale - the subject of Tuesday Tech #8.

Because Advapay covers the license and the core banking platform alongside banking access, the three workstreams tend to move together rather than in sequence - which is usually where the schedule is won or lost. Next week's Tuesday Tech turns to the risk most founders miss: why banking access stalls launches, and how to de-risk it.

Getting IBANs and reaching SEPA and SWIFT is less about the identifiers and the acronyms than about the access behind them and the back-office that runs them. The fintechs I've seen get this right tend to start partnered to get live, choose connectivity that matches their volumes rather than their ambitions, and build on a core where issuance, routing, and reconciliation already sit together. If there's one thing worth deciding early, it's how the money will move - ideally before the license arrives, not after.

If it would help to pressure-test the fastest credible route to IBANs and the rails for your model, Advapay's team is happy to talk it through.