Neobanks & Challenger Banks.
The full infrastructure stack, without the twelve-month build.

Launching a neobank or challenger bank in Europe remains operationally harder than the headlines suggest. Securing a BIN sponsorship, negotiating IBAN issuance, wiring together a core banking ledger, threading in KYC/AML tooling, and passing PSD2 SCA audits — each workstream alone can consume quarters of engineering time and compliance resource. Codego has pre-integrated all of it. Founded in 2012 and headquartered in Malta, Codego operates an end-to-end Banking-as-a-Service stack covering Visa and Mastercard card programmes, native EU IBAN issuance across six countries, real-time multi-currency core banking, white-label crypto card support, and a regulatory envelope that spans the EU's AML directives and PSD2. The result: a fully operational neobank architecture reachable in fifteen days, not fifteen months.

The industry challenge

The European neobank market has matured considerably since 2015, and so has the scrutiny applied to it. Regulators across the EEA have tightened their grip on electronic money institutions, raised capital thresholds, and issued guidance that increasingly expects challenger banks to demonstrate real-time transaction monitoring, documented AML risk frameworks, and end-to-end SCA compliance from day one of commercial operation. This is not the environment in which a minimum-viable product can quietly acquire users while compliance is retrofitted.

The licensing question is the first fork in the road. An Electronic Money Institution (EMI) licence — obtained directly or via passporting from a licenced issuer — allows a neobank to issue IBANs, hold funds, and issue payment cards without the full capital burden of a credit institution. However, an EMI scope prohibits lending, limits interest accrual structures, and requires a third-party BIN sponsor for card scheme participation unless the EMI holds its own principal membership. Full bank licences offer broader product scope but carry multi-year authorisation timelines, substantial capital requirements (typically €5m+ minimum for a small credit institution), and ongoing prudential reporting obligations to national competent authorities. A third model — operating as a programme manager beneath an established licenced entity — lets challengers reach market fastest, trading some product flexibility for speed and cost efficiency.

Parallel to licensing, card scheme access is non-trivial. Both Visa and Mastercard require prospective issuers to either achieve principal membership (a years-long, capital-intensive process) or operate under an existing BIN sponsor. BIN sponsorship relationships are scarce, and sponsors apply their own technical certification requirements on top of the scheme's. Many neobanks discover mid-build that their chosen sponsor supports only one scheme, forcing a second separate integration to cover the other.

IBAN issuance presents its own complexity. Offering a customer a genuine EU IBAN — one that routes correctly through SEPA and SEPA Instant rails — requires either direct participation in the payment scheme or a sponsored access arrangement with a participating institution. The geography matters: an IBAN issued in one jurisdiction may carry different regulatory obligations, consumer trust perceptions, and currency handling characteristics than one issued in another. Neobanks targeting pan-European customers need multi-country IBAN capability, not a single-country workaround.

Beneath all of this sits the core banking ledger. A production-grade ledger for a neobank must handle multi-currency balances in real time, post transactions idempotently, reconcile against card scheme settlement files and SEPA clearing batches, support fee engines and product configuration, and generate the audit trail that regulatory reporting demands. Building this capability from scratch is routinely underestimated; maintaining and scaling it while simultaneously managing scheme compliance and customer operations is a significant ongoing operational burden for any team.

Finally, KYC and AML obligations under the EU's successive AML directives require robust, documented customer due diligence processes — including sanctions screening, politically exposed persons checks, and ongoing transaction monitoring — from the moment a customer onboards. Regulators no longer accept a promise to implement these controls later.

What banking infrastructure must deliver

Dual-scheme card issuance with BIN sponsorship

A neobank that can offer only Visa or only Mastercard immediately narrows its addressable market and creates friction with merchants and customers who carry a preference. Production-ready BIN sponsorship on both schemes — with a single integration surface — eliminates the dual-vendor negotiation problem. Infrastructure must also handle virtual card issuance (day one), physical card personalisation and fulfilment (typically within a fortnight), and digital wallet provisioning for Apple Pay and Google Pay without separate scheme integrations. The card issuing layer must also support multiple BINs per programme, enabling product differentiation — standard, premium, corporate — on a single back-end.

Native EU IBAN issuance across SEPA rails

A genuine EU IBAN — not a virtual IBAN overlaid on a third party's account — gives the neobank full control over inbound payment routing, reconciliation, and the customer experience of receiving salary or transfers. Infrastructure must support SEPA Credit Transfer, SEPA Direct Debit, and SEPA Instant where available. Multi-country IBAN capability matters for programmes targeting customers across the EEA who may have specific expectations around national IBAN prefixes. SWIFT access for international receipts and disbursements is an additional requirement for neobanks serving SME or international-mobility customers who regularly transact outside the eurozone.

Real-time, multi-currency core banking ledger

The core banking ledger is the source of truth for every customer balance, transaction, fee, and interest accrual. It must post in real time — not in end-of-day batch — so that card authorisations, inbound SEPA credits, and FX conversions are immediately reflected in the customer's available balance. Multi-currency support must be native, not bolted on; an architecture that converts everything to a base currency and back introduces FX risk and reconciliation complexity. The ledger must also be configurable enough to support multiple product types — current accounts, savings pots, expense wallets, corporate sub-accounts — without bespoke engineering for each new product variant.

Embedded KYC/AML and regulatory compliance

Neobanks cannot source KYC/AML as an afterthought. The infrastructure layer must provide documented, auditable customer due diligence workflows — identity verification, document checks, sanctions and PEP screening, risk scoring — that satisfy the requirements of EU AML directives and can be evidenced to national competent authorities on request. Ongoing transaction monitoring must run in real time against configurable rule sets, with case management tooling for analyst review. PSD2 Strong Customer Authentication must be implemented correctly for every payment initiation and account access event. Compliance functionality embedded in the infrastructure layer means neobanks do not need to assemble and integrate a separate compliance technology stack.

White-label mobile and web experience

A neobank's product differentiation lives in its user experience. Infrastructure must therefore expose clean, well-documented APIs and, ideally, mobile SDKs that allow the neobank's product team to build a branded experience without reverse-engineering undocumented internal system behaviour. A white-label bank layer — covering account dashboards, card controls, transaction history, push notifications, and onboarding flows — dramatically reduces time to first user while leaving the neobank free to customise. The infrastructure provider's self-service portal should also allow programme managers to configure card controls, spending limits, fee structures, and product parameters without raising engineering change requests.

Crypto and stablecoin card capability

A growing segment of neobank propositions is built explicitly for crypto-native or crypto-curious users: customers who hold stablecoins or volatile crypto assets and want to spend them at any card-accepting merchant without manual conversion steps. This requires infrastructure that can hold or custody crypto balances, convert to fiat at the point of authorisation with real-time FX and crypto pricing, and settle to the card scheme in the scheme's required settlement currency. This capability must be first-class — not a workaround — and must sit within the same compliance envelope as the fiat card programme. A white-label crypto card layer that integrates directly with the core card issuing stack removes the need for a separate crypto payment processor.

How Codego's stack maps to neobanks and challenger banks

Codego's infrastructure is designed around the specific operational pattern of a neobank or challenger bank programme: a licensed or licence-seeking entity that needs card issuance, IBAN infrastructure, core banking, and compliance capability assembled into a coherent, API-accessible stack, without a multi-year integration project. The following describes how Codego's product layers map to each requirement.

BaaS foundation and licensing envelope. Codego operates as a Banking-as-a-Service provider under an NBB electronic-money distribution licence, with Codego Europe SIA currently in the EMI authorisation process and pan-EU passporting in place. This means a neobank operating as a programme manager beneath Codego's regulatory umbrella can reach market immediately, without waiting for its own EMI authorisation to complete. For neobanks that already hold or are obtaining their own EMI licence, Codego operates as the technical infrastructure layer — providing the BaaS stack, BIN sponsorship, and IBAN access — while the neobank retains its own regulatory relationship with its national competent authority. Both operating models are supported. See Codego's BaaS glossary entry for a detailed breakdown of the regulatory architecture.

Card programme on Visa and Mastercard. Codego holds BIN sponsorship on both Visa and Mastercard — a combination that remains uncommon among European BaaS providers and eliminates the need for the neobank to negotiate two separate scheme relationships. The card issuing capability supports virtual cards from day one of programme configuration, with physical card production and personalisation available within fifteen days of programme go-live. Apple Pay and Google Pay provisioning is handled within twenty-four hours of card issuance. Multiple BIN ranges can be allocated to a single programme, enabling the neobank to differentiate product tiers — consumer, premium, business — under a single integration. For neobanks running corporate or SME expense programmes, expense cards with configurable spend controls and category restrictions are available within the same stack.

EU IBAN issuance and SEPA rails. Codego issues native EU IBANs in six countries, with support for SEPA Credit Transfer, SEPA Direct Debit, SEPA Instant, and SWIFT for international transactions. This is not a virtual IBAN overlay; IBANs are issued under Codego's direct or sponsored participation in the relevant payment schemes, giving the neobank full control over inbound routing and reconciliation. Multi-currency account support is native to the core banking ledger, meaning customers can hold EUR, GBP, USD, and other supported currencies in discrete sub-accounts without the neobank building a separate FX and currency management layer.

White-label product layer. Codego's white-label bank product provides a configurable, branded account and card experience — mobile-ready, API-driven, with a self-service portal for programme configuration. Neobanks that want to ship a functioning product quickly without building every UI component from scratch can use this layer as a baseline, then customise progressively as their product team builds proprietary features. For neobanks whose brand proposition is centred on crypto or digital assets, the white-label crypto card product provides stablecoin and crypto-funded card capability with on-the-fly conversion, sitting within the same compliance and settlement architecture as the fiat card programme — no separate crypto payment processor required.

Compliance and regulatory reporting. KYC/AML tooling, PSD2 SCA enforcement, and EU AML directive compliance are embedded in the Codego stack, not sourced separately. Regulatory reporting outputs — transaction data, reconciliation files, suspicious activity reporting workflows — are available through the platform. For neobanks with their own compliance teams, Codego's infrastructure provides the data and tooling; for those operating beneath Codego's regulatory umbrella, the compliance framework is provided as part of the programme arrangement.

The combined effect: a neobank using Codego's full stack — BaaS, card issuing, core banking, white-label bank, and optionally white-label crypto — can reach a testable, compliant, card-and-IBAN product in approximately fifteen days, compared with the twelve-to-eighteen month timeline typical of assembling equivalent capability from component vendors.

Real-world architecture

The following describes a representative architecture adopted by a European consumer neobank targeting the underbanked and internationally mobile population across three EU member states. Details are anonymised.

Context. The operator was a fintech holding company with no prior payment institution history. Their target customers were EU residents who required a genuine local IBAN for salary receipt, a Visa debit card for everyday spending, and a simple mobile app with multi-currency wallet functionality. A secondary use case — crypto-funded card top-ups for a subset of users — was identified early in product planning but initially descoped to avoid complexity.

Licensing approach. Rather than pursuing an independent EMI authorisation — estimated at nine to fourteen months — the operator chose to launch as a programme manager beneath an existing licenced entity's regulatory envelope, targeting a later transfer to their own licence once the product had demonstrated traction. This decision reduced time to revenue by over a year and avoided committing significant capital to a regulatory process before product-market fit was established.

Technical stack. The operator connected to Codego's API layer for IBAN issuance and core banking ledger access, card programme configuration on Visa (primary) and Mastercard (backup BIN for specific markets), and KYC/AML workflow integration. Their mobile application — built natively on iOS and Android by an in-house team of four engineers — consumed Codego's APIs directly for all account, card, and transaction operations. The white-label SDK handled card control UI components (freeze/unfreeze, spending limits, PIN management), reducing the in-house engineering scope by an estimated forty percent versus a fully bespoke build.

Go-live timeline. Programme configuration was completed within ten days of commercial agreement. Virtual cards were issued to internal testers on day eight. Physical card fulfilment began on day fourteen. Apple Pay provisioning was live within twenty-four hours of the first virtual card issuance. The first external customer onboarded on day seventeen — three days beyond the fifteen-day target, attributable to an extended KYC document review queue during initial calibration of the operator's onboarding flow.

Crypto top-up — phased addition. Six months post-launch, the operator activated the white-label crypto card capability. Customers could link a self-custody wallet or exchange account, convert stablecoins (USDC and USDT supported) to EUR at the point of authorisation, and spend on their existing Visa card without a separate card issuance event. This was configured through the self-service portal and required no API integration changes on the operator's side — the crypto conversion layer sat entirely within Codego's settlement architecture.

Trade-offs observed. Operating beneath a third-party regulatory umbrella imposed constraints on certain product decisions — specifically, fee structures and credit-adjacent features — that required sign-off from the licencing entity rather than unilateral product changes. The operator accepted this as a reasonable constraint for the early phase, with a roadmap to independent EMI authorisation as the programme scaled. The absence of a bespoke core banking build meant that certain highly specific ledger behaviours required platform-level feature requests rather than direct code changes — a consideration for neobanks with highly differentiated product requirements.

Frequently asked questions

How does the fifteen-day launch timeline actually work — what is included and what is not?

The fifteen-day timeline covers programme configuration, BIN allocation on Visa and/or Mastercard, EU IBAN provisioning, core banking ledger setup, KYC/AML workflow activation, and virtual card issuance. Physical card production begins in parallel from day one of programme configuration and typically completes within the same window. What the timeline does not include is the operator's own mobile or web application development — Codego provides APIs and optional white-label SDK components, but the operator's product team builds and manages the customer-facing application. Regulatory onboarding documentation for programme managers operating beneath Codego's licence must also be completed prior to the clock starting; this typically takes two to five business days depending on the operator's corporate structure and jurisdiction.

Can a neobank use Codego's infrastructure while holding its own EMI licence?

Yes. Codego operates in two modes: as a licenced umbrella for operators who do not yet hold their own payment institution authorisation, and as a pure infrastructure provider for operators who hold their own EMI or are in the authorisation process. In the latter case, Codego provides BIN sponsorship on Visa and Mastercard, IBAN issuance, core banking ledger access, and card programme infrastructure, while the operator maintains its own regulatory relationship with its national competent authority and retains full control over its compliance framework. The API surface is identical in both modes; the contractual and regulatory structure differs. For neobanks in the EMI authorisation process, Codego's infrastructure can be used to launch under the umbrella arrangement and then transitioned to the direct model when authorisation is granted.

What is the difference between a full BaaS arrangement and partial BaaS — which model suits a neobank?

A full BaaS arrangement means the neobank operates entirely beneath the infrastructure provider's regulatory and technical stack — licence, BIN sponsorship, IBAN, core banking, and compliance are all provided. A partial BaaS arrangement means the neobank holds its own licence and sources specific infrastructure components — typically card issuing and IBAN — from the BaaS provider while running its own compliance and potentially its own ledger. Full BaaS is appropriate for early-stage neobanks prioritising speed and capital efficiency; partial BaaS suits operators with existing licences or highly differentiated product requirements that demand bespoke ledger behaviour. Codego supports both; the distinction is primarily contractual and determines where regulatory accountability sits. See the BaaS glossary entry for a detailed breakdown.

Does Codego support both Visa and Mastercard simultaneously for the same programme?

Yes. Codego holds BIN sponsorship on both Visa and Mastercard, and a neobank programme can be configured to issue on either or both schemes simultaneously. Dual-scheme capability is typically used to allocate different BIN ranges to different product tiers — for example, Visa for a consumer product and Mastercard for a business or corporate product — or to provide geographic redundancy where one scheme has stronger merchant acceptance in a specific market. The card issuing API and self-service portal treat both schemes through a single integration surface; the neobank does not need to manage two separate technical relationships. See card issuing and BIN sponsorship for further technical detail.

How does the white-label crypto card work, and is it compliant with EU regulations?

The white-label crypto card allows a neobank to offer customers a card that can be funded from a crypto or stablecoin balance. When a customer makes a card payment, the conversion from crypto (or stablecoin) to the transaction currency happens in real time at the point of authorisation; the merchant receives settlement in fiat through the standard Visa or Mastercard settlement process. The neobank's customer never needs to pre-convert manually. The crypto conversion layer operates within Codego's existing compliance architecture — KYC/AML obligations applied at onboarding and ongoing transaction monitoring cover both fiat and crypto-funded activity. The product is designed for EU regulatory compliance, including Travel Rule obligations where applicable, though neobanks should obtain independent legal advice regarding any additional obligations specific to their own jurisdiction and product structure.

What regulatory reporting obligations does Codego's infrastructure support?

Codego's core banking and card infrastructure generates the transaction data, reconciliation files, and audit trails required for standard regulatory reporting obligations applicable to payment institutions and electronic money institutions under EU regulation. This includes transaction-level data exportable for AML suspicious activity reporting, SEPA clearing reconciliation data, and card scheme settlement file processing. For neobanks operating beneath Codego's regulatory umbrella, the reporting obligations to the relevant national competent authority are managed at the licencing entity level, with the neobank's programme data feeding into that reporting. For neobanks with their own EMI licence, Codego provides data exports in formats compatible with standard regulatory reporting workflows; the neobank's own compliance team is responsible for preparing and submitting reports to its regulator.

Neobanks & Challenger Banks.The full infrastructure stack, without the twelve-month build.