Category: Reference Articles

What is the difference between PaaS and BaaS?

What is a BIN in payment card issuing

Payments as a Service (PaaS) and Banking as a Service (BaaS) are related but structurally different models. PaaS provides the infrastructure to make and receive payments, issue cards and manage compliance – all underpinned by an Electronic Money Institution (EMI) licence. BaaS provides a broader set of banking capabilities, including deposit accounts, lending and credit, and is typically underpinned by a banking licence. A business that needs to issue cards, process payments or disburse funds needs PaaS. A business that needs to offer deposit accounts or credit products needs BaaS.

On this page:

  • What does PaaS cover that BaaS does not, and vice versa?
  • What is the regulatory difference between PaaS and BaaS?
  • Which licence does a PaaS provider hold, and why does it matter?
  • Can a BaaS provider also offer PaaS, and what are the risks?
  • How does the European market consolidation relate to the PaaS and BaaS distinction?
  • How do I know which model I actually need?
  • Where does BIN sponsorship fit in relation to PaaS and BaaS?

What does PaaS cover that BaaS does not, and vice versa?

Answer

PaaS covers payment infrastructure: card issuing, transaction processing, scheme connectivity, settlement and payment compliance. BaaS covers banking infrastructure: everything PaaS covers, plus deposit accounts, lending, credit facilities and a banking licence. PaaS is the correct and sufficient model for most businesses that need to embed payment capability.

What PaaS covers

A PaaS provider holds an EMI licence, principal membership of Visa and Mastercard, and the processing infrastructure to handle real-time authorisation, clearing and settlement. Clients access card issuance, funds disbursement, multi-currency settlement, fraud monitoring and AML controls without building or licencing any of it themselves.

What BaaS adds to PaaS

BaaS extends the payment model to include banking-grade products: deposit accounts, lending and credit facilities, and supervision by a prudential regulator as well as a conduct regulator. BaaS is the appropriate model for businesses that need to offer deposit accounts to end users, provide credit products, or require banking-grade deposit protection rather than EMI-level e-money safeguarding.

What to watch for

  • Many providers describe themselves as BaaS providers while operating under an EMI licence rather than a banking licence. The label matters less than the actual licence the provider holds and what it permits them to do on your behalf.
  • A business that only needs card issuing and payment processing does not need BaaS. Confirm what licence underpins the service and whether it matches your actual product requirements.

What is the regulatory difference between PaaS and BaaS?

Answer

PaaS operates under an EMI licence, which authorises the issuance of electronic money and the provision of payment services. BaaS operates under a banking licence, which additionally authorises the acceptance of deposits and the provision of credit. These are separate regulatory regimes with different supervisory authorities, capital requirements and compliance obligations. The distinction determines what the provider can legally offer, and therefore what you can build on top of their infrastructure.

The EMI licence and what it permits

An EMI licence is issued by a financial regulator – the FCA in the UK or the Bank of Lithuania in the EU, for example – and authorises the holder to issue electronic money, process transactions, hold funds as e-money, and manage payment flows across multiple currencies and geographies. It does not permit the provider to accept deposits, lend money or offer credit products.

The banking licence and what it adds

A banking licence permits all of the above, plus the acceptance of deposits, the provision of credit, and participation in national deposit guarantee schemes. Banking licence holders are supervised by both a conduct regulator and a prudential regulator, which adds capital adequacy obligations and balance sheet requirements that an EMI does not carry

What to watch for

  • Ask your prospective PaaS provider exactly which licence they hold and in which jurisdiction it was granted. An EMI licence granted in one EU member state can be passported across the EEA, but the home regulator’s standards and the provider’s compliance history both matter.
  • If a provider describes themselves as BaaS but cannot confirm they hold a banking licence, they are offering EMI-based PaaS under a different label. Understand what you are actually buying.

Which licence does a PaaS provider hold, and why does it matter?

Answer

A PaaS provider holds an EMI licence. This matters because it determines what the provider can legally do on your behalf, what protections apply to the funds held in the arrangement, and how the provider is supervised. For most businesses using PaaS to issue cards or manage payment flows, an EMI licence is the correct and sufficient regulatory basis.

How funds are protected under an EMI licence

Under an EMI licence, customer funds must be safeguarded in segregated accounts with a qualifying institution, held separately from the provider’s own funds. This is distinct from deposit protection under a banking licence, which in many jurisdictions includes a government-backed guarantee scheme. For most PaaS use cases – card programmes, disbursements, payment flows – this distinction is not commercially material. For products that require deposit-level protection, a banking licence is needed.

Why the issuing regulator matters

Not all EMI licences are equivalent. The supervisory standards applied by different European regulators vary, and a provider licenced in a jurisdiction known for lighter-touch supervision may not meet the same standards as one supervised by the FCA or the Bank of Lithuania. A provider that has held a clean licence for a decade across two jurisdictions has demonstrated regulatory standing in a way that a recently licenced provider has not.

What to watch for

  • Confirm the specific licence number and issuing regulator for any provider you are evaluating. Cross-reference against the regulator’s public register to verify the licence is current and unrestricted.
  • Ask how long the provider has held its licence and whether it has ever been subject to supervisory restrictions, special measures or sanctions.
  • For multi-market programmes, confirm the provider holds authorisation in the jurisdictions your programme will operate in, not just the ability to passport from a single home state.

Can a BaaS provider also offer PaaS, and what are the risks?

Answer

Yes. A BaaS provider with a banking licence can offer PaaS-equivalent payment services alongside deposit and credit products. The risk is not in the model itself but in scope: a banking-licenced provider is managing credit risk, liquidity risk and capital adequacy alongside payment compliance. If the banking side of the business encounters regulatory difficulty, the payment infrastructure a client depends on may be affected even if their programme has nothing to do with the problem.

What a banking licence means for compliance scope

Banking licences require the management of obligations that an EMI does not carry. A provider that has built its business around banking-grade products is managing a more complex compliance environment than one focused specifically on payment infrastructure. When compliance failures have occurred in the European market, they have often arisen from the difficulty of managing banking-grade obligations at embedded finance scale and pace.

What to ask if your provider holds a banking licence

If your programme only requires payment capability, ask whether the payment infrastructure and compliance oversight are operationally separated from the banking side of the business, and whether a regulatory restriction on the banking operations would affect your payment programme.

What to watch for

  • A banking licence does not automatically signal greater safety for a payment programme client. It signals a broader and more complex regulatory scope that may or may not be relevant to your needs.
  • If your programme only needs PaaS capability, evaluate whether the additional compliance scope of a banking-licenced provider adds risk rather than value to your specific situation.

How does the European market consolidation relate to the PaaS and BaaS distinction?

Answer

The regulatory difficulties that several European providers faced between 2022 and 2025 occurred predominantly in the BaaS segment: providers offering banking-grade infrastructure at embedded finance scale without adequate compliance controls. The consolidation is a reminder that the model a provider operates under, and their compliance track record within it, are material risk factors for clients.

Why the BaaS model has faced more scrutiny

Banking-licenced providers carry obligations across credit risk, liquidity management, capital adequacy and payment compliance simultaneously. Providers that expanded rapidly in the low-interest-rate environment of 2020 to 2022 took on compliance obligations at a scale their infrastructure had not kept pace with. When regulators audited those obligations, the deficiencies were significant.

What this means when choosing a provider

The consolidation does not mean BaaS is wrong for all buyers. It means the compliance track record, financial standing and regulatory history of any provider should be examined before committing. The questions are the same regardless of label: how long have they held their licence, have they been subject to supervisory restrictions, and what is their financial position?

What to watch for

  • Do not assume a provider describing itself as PaaS is automatically lower risk than one describing itself as BaaS. The licence, the regulatory track record and the financial standing matter more than the label.
  • Ask any prospective provider whether they have ever been subject to regulatory sanctions, restrictions on new business or special supervisory measures, and ask for the answer in writing.

How do I know which model I actually need?

Answer

If you need to issue cards, process payments, disburse funds or manage payment flows, you need PaaS. If you need to offer deposit accounts, provide credit or lending products, or require deposit guarantee scheme protection for your end users, you need BaaS or a banking licence. Most businesses evaluating payment infrastructure find that PaaS is the correct and sufficient model.

A simple decision framework

Your requirement PaaS BaaS
Issue branded Visa or Mastercard cards Yes Yes
Process and settle card transactions Yes Yes
Disburse funds to recipients Yes Yes
Multi-currency settlement across European markets Yes Yes
Fraud monitoring and AML compliance for payment flows Yes Yes
Offer deposit accounts to end users No Yes
Provide credit or lending products No Yes
Deposit guarantee scheme protection for end users No Yes (in most cases)
Manage banking balance sheet obligations No Yes

Where does BIN sponsorship fit in relation to PaaS and BaaS?

Answer

BIN sponsorship is the card scheme participation arrangement within a PaaS model that enables a client to issue Visa or Mastercard cards. When a PaaS provider holds principal membership of Visa and Mastercard and extends that membership to a client, enabling them to issue cards as an affiliate member of the scheme, that is BIN sponsorship. It is a component of PaaS where card issuance is required, not a separate model.

A client using a PaaS provider only for funds disbursement or open banking may not need BIN sponsorship at all. BIN sponsorship is specific to card issuance within the EMI-based PaaS model and does not apply in the same way to BaaS arrangements underpinned by a banking licence.

For a full explanation of how BIN sponsorship works, who uses it and what to look for in a provider, see: BIN sponsorship explained: the complete guide for fintechs and PSPs.

 

Related pages

 

Evaluating a PaaS provider for your programme?

DiPocket is a dual-regulated EMI and principal member of both Visa and Mastercard, authorised by the FCA (Reference No. 900439) and the Bank of Lithuania (Licence No. 75), operating payment programmes across 15 European markets. Explore DiPocket’s PaaS and BIN sponsorship services.

What does a PaaS provider cover, and what stays with the client?

What is a BIN in payment card issuing

A PaaS provider covers the regulated infrastructure layer: the EMI licence, principal scheme membership, transaction processing, PCI DSS compliance, AML monitoring infrastructure, scheme rule management and settlement. The client covers the customer-facing layer: KYC and customer onboarding, the cardholder relationship, programme design decisions, and compliance with sector-specific regulations that apply to their own business. The precise division is set out in the programme agreement, which is the most important document in any PaaS arrangement.

On this page:

  • What does the PaaS provider take on?
  • What does the client remain responsible for?
  • What does the contract with a PaaS provider need to cover?
  • Where are the common grey areas in PaaS responsibility?
  • Who is responsible for KYC in a PaaS arrangement?
  • Who is responsible for transaction monitoring and fraud?
  • What questions should I ask before signing a contract with a PaaS provider?

What does the PaaS provider take on?

Answer

A PaaS provider takes on the regulated infrastructure layer: the licences, scheme membership, processing technology, compliance monitoring and settlement. In a well-structured arrangement, the client does not need to employ compliance resource to manage scheme rules, technology teams to maintain processing infrastructure, or legal resource to track regulatory change.

Why the provider’s licence matters to your programme

The provider holds the authorisations that make the programme possible. In Europe, this means an EMI licence from a recognised regulator – the FCA in the UK or the Bank of Lithuania in the EU, for example. The provider is also the entity responsible to Visa and Mastercard for compliance with scheme rules across all programmes running under its BINs. The client does not need to hold these authorisations or manage these relationships directly.

What the provider’s processing infrastructure covers

The provider operates the processing platform that handles real-time transaction authorisation, card lifecycle management, tokenisation for mobile wallets, and the data feeds that drive reporting and reconciliation. They also maintain PCI DSS certification for the card data environment and manage the implementation of scheme rule updates as they are released by Visa and Mastercard.

What to watch for

  • Confirm that the provider’s EMI licence covers all the markets and currencies your programme will operate in. Principal membership of both Visa and Mastercard gives flexibility to issue on either scheme; single-scheme membership does not.
  • Ask specifically whether the provider operates its own authorisation platform or relies on a third-party processor. Each additional intermediary in the chain is a potential point of latency and an additional relationship your programme depends on.

What does the client remain responsible for?

Answer

The client retains responsibility for the customer-facing layer: KYC and customer onboarding, the end-user relationship, programme design decisions, and compliance with sector-specific regulations that apply to the client’s own business. The provider’s licences and compliance infrastructure do not cover these obligations. Understanding exactly where the client’s responsibilities begin – and where the grey areas are – is the most important due diligence task before signing.

Customer-facing compliance

The provider’s AML infrastructure monitors transactions across the programme, but the client is responsible for conducting and documenting KYC checks on its own customers at the point of onboarding. The standard to which KYC must be conducted is set by the provider (reflecting their regulatory obligations) and by applicable law. If a customer onboarding fails to meet that standard, the risk sits with the client.

Programme design and product decisions

Spend controls, card limits, merchant category restrictions, the cardholder agreement, and the design of the card product are the client’s domain. The provider configures these in the programme, but the decisions are the client’s to make and the client’s to defend if they are challenged. A client who configures inappropriate spend controls, or fails to update them when the product changes, carries that responsibility.

What to watch for

  • The cardholder relationship is the client’s, not the provider’s. Complaints, disputes and escalations from cardholders are the client’s responsibility to handle, even where the underlying issue involves the provider’s infrastructure.
  • Sector-specific regulations – financial services, healthcare, government, for example – apply to the client’s own business independently of the PaaS arrangement. The provider’s licences do not cover sector-specific obligations the client’s business attracts on its own.

What does the contract with a PaaS provider need to cover?

Answer

The contract between a PaaS provider and a client – known in the industry as a programme agreement – sets out who is responsible for what across every aspect of the payment programme, and the terms under which either party can exit the arrangement. It defines the compliance obligations of each party, the service levels the provider commits to, the client’s permitted use of the programme, and the data ownership and sharing arrangements.

Why it is the most important document in the arrangement

Ambiguity in the programme agreement creates risk for both parties, but the risk typically falls harder on the client, who has less experience reading these documents and less negotiating leverage. In the event of a compliance incident, a dispute with a regulator, a cardholder complaint that escalates, or a decision to change provider, the programme agreement is the document that determines who is liable for what.

What to review before signing

Before signing, both parties should be clear on: who conducts KYC checks and to what standard, who monitors transactions for fraud and AML and what happens when a suspicious transaction is flagged, how customer complaints are handled and at what point the provider is involved, what the data ownership and data sharing arrangements are, what the notice period and migration obligations are if either party wants to exit, and under what circumstances the provider can suspend or terminate the programme.

What to watch for

  • Do not sign a programme agreement without legal review. The compliance obligations, liability provisions and exit terms have material commercial and regulatory consequences that are not visible from a commercial term sheet.
  • Pay specific attention to the exit and migration provisions. Understanding what it would take to move to a different provider – the notice period, the data portability obligations, the card re-issuance requirements – is essential context for the decision to sign.

Where are the common grey areas in PaaS responsibility?

Answer

The most common grey areas in PaaS responsibility are: who conducts enhanced due diligence on high-risk customers, who is responsible for ongoing transaction monitoring for a specific client’s customer base, who handles a disputed transaction when the client and the provider disagree on the root cause, what happens to customer data if the programme is terminated, and who is responsible for notifying regulators in the event of a compliance incident.

Enhanced due diligence and high-risk customers

Standard KYC is the client’s responsibility. Enhanced due diligence (EDD) for high-risk customers – politically exposed persons, customers from higher-risk jurisdictions, customers with unusual transaction patterns – may sit with the client, the provider, or both, depending on the programme agreement. This is one of the most frequently underdefined areas in programme agreements and one of the most frequently cited in regulatory enforcement actions against the European PaaS and BaaS sector.

Ongoing transaction monitoring

The provider’s AML infrastructure monitors transactions across all programmes at a system level. Monitoring specific to the risk profile of the client’s own customer base – the patterns that would be unusual for that type of customer but not unusual for the programme as a whole – is typically the client’s responsibility to design and implement. The boundary between these two is often unclear in programme agreements and should be explicitly defined before launch.

Data ownership and portability on exit

When a programme ends or migrates to a new provider, the question of who owns the cardholder data, in what format it can be extracted, and under what conditions it can be transferred is frequently disputed. Cardholder data held in the provider’s certified PCI DSS environment is subject to strict transfer conditions. The programme agreement should specify the client’s data portability rights in the event of exit.

What to watch for

  • Ask the provider to walk you through their EDD process for high-risk customers and confirm in writing whether EDD responsibility sits with them, with you, or is shared and on what basis.
  • Ask specifically how cardholder data is handled on programme exit and whether you have a contractual right to extract it in a portable format. Discover this before you sign, not before you migrate.

Who is responsible for KYC in a PaaS arrangement?

Answer

The client is responsible for conducting and documenting KYC checks on its own customers. The PaaS provider sets the KYC standard that must be met, reflecting their regulatory obligations and the requirements of the card schemes, but the actual onboarding checks are the client’s process to design and operate. The provider does not conduct KYC on the client’s customers; it requires the client to do so and may audit compliance with that requirement.

How KYC standards are set in a PaaS arrangement

The provider’s programme agreement sets out the minimum KYC standard the client must apply: which identity documents are acceptable, what verification steps are required, what the rules are for customers from higher-risk jurisdictions, and what records must be kept and for how long. These standards reflect the provider’s own regulatory obligations and cannot be waived. A client who onboards customers to a lower standard than the programme agreement requires is in breach of the agreement and exposed to regulatory risk.

What to watch for

  • Confirm that the KYC standard set by the provider’s programme agreement is operationally achievable for your customer base before signing. KYC requirements for certain customer types – non-EEA residents, business customers with complex ownership structures, high-risk categories – may require significant operational build.
  • Ask whether the provider will audit your KYC processes and on what basis. Understanding their oversight model helps you size the compliance infrastructure your business needs to operate the programme correctly.

Who is responsible for transaction monitoring and fraud in a PaaS arrangement?

Answer

The PaaS provider operates the AML and fraud monitoring infrastructure at a programme level: the system that flags unusual transaction patterns across the whole portfolio and generates suspicious activity reports where required. The client is responsible for monitoring that is specific to its own customer base: understanding what normal behaviour looks like for its own customers, configuring appropriate spend controls, and escalating alerts that the provider’s system generates in relation to their programme.

What the provider’s monitoring covers

The provider’s transaction monitoring system applies rules across all programmes running on its platform. It is designed to detect patterns that are suspicious at a network level – transaction velocities, geographic anomalies, patterns associated with known fraud typologies. It generates alerts that are reviewed by the provider’s compliance team. For alerts that relate to a specific client’s programme, the provider will typically escalate to the client for context before determining next steps.

What the client’s monitoring covers

The client’s monitoring responsibility is contextual: knowing its own customers well enough to recognise when their transaction behaviour is anomalous relative to what would be expected for that customer type. A benefit disbursement platform should expect different transaction patterns from a corporate card programme. Spend controls configured by the client are a first line of defence: a well-designed set of controls reduces the volume of alerts the provider’s system generates for that programme.

What to watch for

  • Ask the provider what their alert escalation process is: when they generate an alert on your programme, how quickly do they notify you, what information do they provide, and what response do they expect from you and in what timeframe?
  • Treat the design of your spend controls as a compliance task, not just a product decision. Appropriate merchant category restrictions and transaction limits are part of your AML obligations, not just features of the card product.

What questions should I ask before signing a contract with a PaaS provider?

Answer

Before signing with a PaaS provider, ask: who is responsible for enhanced due diligence on high-risk customers; how transaction monitoring alerts are escalated and what response is expected from you; what your data portability rights are on exit; what the notice period and migration obligations are; whether you have the right to change the issuer processor independently; and whether the provider has ever been subject to regulatory sanctions or supervisory restrictions.

What to ask about compliance responsibilities

  • Who conducts enhanced due diligence on high-risk customers, and is that obligation defined in the programme agreement or left to discretion?
  • When your monitoring system generates an alert on our programme, what information do you provide, and what response do you expect from us and in what timeframe?
  • What are our obligations if we identify a compliance issue in our own operations that may be relevant to the programme? What is the notification and escalation process?
  • Who is responsible for notifying regulators in the event of a reportable incident, and how are those notifications coordinated between us?

What to ask about your data and exit rights

  • What are our data portability rights if we terminate the programme or migrate to a different provider? In what format and under what conditions can cardholder data be extracted?
  • What is the notice period for termination, and what migration support do you provide to ensure continuity for our cardholders?
  • Do we have the contractual right to change issuer processor independently of this agreement? If not, what is the process for requesting a processor change?

What to ask about the provider’s regulatory history

  • How long have you held your regulatory licences, and in which jurisdictions?
  • Have you ever been subject to regulatory sanctions, supervisory restrictions or special measures from any regulator?
  • Can you provide evidence of your current principal membership status with Visa and Mastercard?

What to watch for

  • A provider who is reluctant to answer these questions, or who provides evasive answers, is telling you something important about the risk of the arrangement.
  • Ask for the answers to the regulatory standing questions in writing and keep them on file. They are part of your own due diligence record and may be relevant if your regulator asks about your third-party risk management.

Related pages

Reviewing a programme agreement with a PaaS provider?

DiPocket is a dual-regulated EMI and principal member of both Visa and Mastercard, authorised by the FCA (Reference No. 900439) and the Bank of Lithuania (Licence No. 75), operating payment programmes across 15 European markets. Explore DiPocket’s PaaS and BIN sponsorship services.

What is embedded finance, and how does it relate to Payments as a Service?

What is a BIN in payment card issuing

For: fintech product and BD leads, platform operators, non-financial businesses considering embedded financial products

Embedded finance is the integration of financial products or services into a non-financial platform or product: a retail app offering credit, a mobility platform offering insurance, a marketplace offering instant payouts. Payments as a Service (PaaS) is one of the primary infrastructure models that makes embedded finance possible – specifically for businesses that need to embed payment capability such as card issuing, funds disbursement or payment processing. PaaS is not the same as embedded finance; it is part of the infrastructure layer that powers it.

On this page:

  • What is embedded finance?
  • What is the difference between embedded finance and Payments as a Service?
  • What financial products can be embedded, and which require PaaS?
  • Does a business need its own licence to offer embedded finance?
  • What is the difference between embedded finance and embedded payments?
  • Who is responsible for compliance in an embedded finance arrangement?
  • How does BIN sponsorship relate to embedded finance?

What is embedded finance?

Answer

Embedded finance is the integration of financial products or services – payments, credit, insurance, savings, investment – into a non-financial platform or product. Rather than a customer leaving a platform to access financial services from a bank or financial institution, the financial product is built into the experience they are already using.

What embedded finance covers

The range of financial products that can be embedded is broad. A retailer offering buy-now-pay-later at checkout, a gig platform offering instant pay to workers, a B2B marketplace offering invoice financing to merchants, a travel platform issuing virtual corporate cards for procurement – all are examples of embedded finance. The defining characteristic is that the financial product is accessed within a non-financial context, powered by regulated infrastructure provided by a third party.

Who holds the licence in an embedded finance arrangement

The regulated infrastructure that powers an embedded finance product – the licences, scheme memberships, processing technology and compliance framework – is held by a third-party provider, not by the non-financial business offering the product. A retailer embedding a card, a platform embedding a payout product, a B2B marketplace embedding invoice financing – none of these businesses needs to hold the regulatory authorisations themselves. They access those authorisations through their provider. This is what makes embedded finance commercially viable for businesses outside the financial sector.

What to watch for

  • Embedded finance is a broad term that encompasses many different product types and infrastructure models. Identifying which financial product you want to embed is the first step. The infrastructure model required (PaaS, BaaS or other) follows from that.
  • Not all businesses that describe themselves as embedded finance providers hold the regulatory licences that underpin the products they offer. Ask any provider to confirm which regulated entity holds the licence for the financial products accessible through their platform.

What is the difference between embedded finance and Payments as a Service?

Answer

Embedded finance describes what a business offers its customers: a financial product integrated into a non-financial platform. Payments as a Service describes the regulated infrastructure that makes it possible: the licences, scheme memberships, processing technology and compliance framework. PaaS is not the same as embedded finance – it is the infrastructure layer that a business builds embedded payment products on top of. A business can offer embedded finance without understanding PaaS; it cannot do so without the infrastructure PaaS provides.

Where PaaS sits in an embedded finance product

It helps to think of embedded finance in three layers. The top layer is the customer experience: the financial product embedded in a non-financial context. The middle layer is the product design and programme management: the decisions about what the product does, how it is governed, and who it is offered to. The bottom layer is the infrastructure: the licences, scheme access, processing technology and compliance framework. PaaS operates at the bottom layer. Embedded finance is the result visible at the top.

When PaaS is and is not sufficient for embedded finance

PaaS is the right infrastructure model for embedded finance that involves payment products: branded cards, disbursements, virtual accounts, spend management, open banking integrations. For embedded finance that involves credit products, deposit accounts or insurance, PaaS alone is not sufficient – those products require different regulatory infrastructure, typically a banking licence or specialist insurance authorisation.

What to watch for

  • If someone describes their platform as an embedded finance solution, ask specifically which financial products it delivers and which regulated entity holds the licence for each one. The answer tells you what infrastructure layer is actually involved.
  • A PaaS provider can power embedded payment products. It cannot power embedded credit or embedded deposit products without a banking licence. Confirm that the infrastructure your provider holds matches the products you want to embed.

What financial products can be embedded, and which require PaaS?

Answer

Payment products – cards, disbursements, virtual accounts, open banking – require PaaS infrastructure, specifically an EMI licence and scheme connectivity. Credit products – buy-now-pay-later, invoice financing, lending – require a credit licence or banking licence. Insurance products require insurance authorisation. Investment products require investment services authorisation. PaaS is specifically the infrastructure model for embedded payment products.

Embedded payment products and what they need

Issuing a branded payment card, enabling instant payouts to workers or merchants, providing a virtual IBAN for payment receipt, building a spend management product with configurable card controls – these all require the card scheme access, EMI licence and processing infrastructure that a PaaS provider holds. The non-financial business delivers the product under the PaaS provider’s regulatory umbrella without needing its own licences.

 

Embedded product Infrastructure needed Does PaaS cover this?
Branded payment card (prepaid, debit) EMI licence, scheme membership Yes
Instant payout to workers or merchants EMI licence, payment processing Yes
Virtual IBAN for payment receipt EMI licence, SEPA/Faster Payments access Yes
Spend management with card controls EMI licence, scheme membership Yes
Open banking (PIS/AIS) EMI or PI licence Yes
Buy-now-pay-later or credit Consumer credit licence or banking licence No
Invoice financing or lending Banking or credit licence No
Savings or deposit accounts Banking licence No
Insurance products Insurance authorisation No

 

What to watch for

  • Some embedded finance platforms bundle multiple product types – payments plus credit, for example – under a single commercial offering. Confirm which regulated entity holds each licence, and whether the licence covers the specific product you need in the markets you intend to operate in.

Does a business need its own licence to offer embedded finance?

Answer

Not necessarily. A non-financial business that embeds payment products through a PaaS provider operates under the provider’s EMI licence and scheme membership. It does not need to hold those licences itself. Whether the business needs its own regulatory authorisation depends on the specific products offered, the markets it operates in, and the nature of its relationship with the end user and with customer funds.

When the provider’s licence is sufficient

For most embedded payment products – branded cards, disbursements, virtual accounts – the PaaS provider holds the licences and the non-financial business operates as a programme client under the provider’s regulatory umbrella. The business is responsible for its customer-facing compliance obligations (KYC, customer onboarding, the cardholder relationship) but does not need its own EMI or scheme membership.

When the business may need its own authorisation

If the business holds customer funds in its own name, operates in a way that constitutes e-money issuance, or provides payment services that require its own authorisation under PSD2, it may need a Payment Institution (PI) or EMI licence regardless of the PaaS arrangement. The FCA’s guidance on EMI authorisation sets out the relevant thresholds for UK businesses. This is a question to resolve with both the PaaS provider and legal advisers before launch.

What to watch for

  • The programme agreement with a PaaS provider sets out what the provider covers and what the client is responsible for. Read it carefully, and specifically check how customer funds are held and in whose name.
  • If your embedded finance product involves holding or managing customer funds beyond the immediate execution of a payment transaction, take specific legal advice on whether you need your own regulatory authorisation.

What is the difference between embedded finance and embedded payments?

Answer

Embedded payments is a subset of embedded finance. Embedded payments refers specifically to the integration of payment acceptance or payment processing into a non-financial platform – a software company building payment processing into its product, for example. Embedded finance is the broader category, encompassing payments plus credit, insurance, savings and other financial products. All embedded payments are embedded finance; not all embedded finance is payments.

Why the distinction matters for infrastructure decisions

A business embedding payment issuance – enabling its customers to make payments via a branded card, a virtual account or a disbursement – needs PaaS and issuing infrastructure. A business embedding payment acceptance – enabling its merchants or users to receive card payments – needs acquiring infrastructure. The two are different parts of the payment stack with different providers and different regulatory frameworks. Confirming which capability your embedded finance product actually requires determines which infrastructure model and which type of provider you need.

What to watch for

  • ‘Embedded payments’ in a product context often means payment acceptance for merchants. If your use case is issuing cards or disbursing funds rather than accepting payments, confirm that your provider’s infrastructure covers issuing, not just acquiring.

Who is responsible for compliance in an embedded finance arrangement?

Answer

Compliance responsibility is divided between the infrastructure provider and the business offering the embedded product. The PaaS provider holds the regulatory licences, maintains scheme rule compliance, operates the AML monitoring infrastructure and manages PCI DSS for the card data environment. The business offering the embedded product is responsible for its own customer-facing compliance: KYC and customer onboarding, the end user relationship, and compliance with any sector-specific regulations that apply to its own business.

How the programme agreement defines the compliance division

The precise division is set out in the programme agreement between the PaaS provider and the business. It is one of the most important documents in any embedded finance arrangement and should be reviewed carefully. The common areas of ambiguity are: who conducts KYC checks on end users, who is responsible for transaction monitoring for the client’s specific customer base, and how compliance incidents are escalated and managed. Clarity on these points before launch is significantly easier to achieve than after.

What to watch for

  • Do not assume that because a PaaS provider handles ‘compliance’, your business has no compliance obligations. The provider handles regulatory infrastructure compliance. You handle customer-facing compliance for your own end users.
  • If your embedded finance product serves a sector with its own regulatory requirements – financial services, healthcare, government – confirm whether those sector-specific obligations fall to you or to the provider, and get the answer in writing in the programme agreement.

How does BIN sponsorship relate to embedded finance?

Answer

BIN sponsorship is the specific card scheme participation arrangement used within a PaaS model when a business wants to issue branded Visa or Mastercard cards as part of an embedded finance product. When a non-financial business embeds a branded card into its platform, the card is issued under the PaaS provider’s BIN – the provider holds principal membership of the scheme and extends that membership to the client. BIN sponsorship is the mechanism; embedded finance is the product experience it enables.

A business embedding a card product into its platform is, by definition, using BIN sponsorship as part of the PaaS arrangement. A business embedding only payment acceptance or open banking functionality may not be using BIN sponsorship at all.

For a full explanation of how BIN sponsorship works within a card programme, see: BIN sponsorship explained: the complete guide for fintechs and PSPs.

What is the difference between principal membership and affiliate membership?

What is a BIN in payment card issuing

Principal members hold a direct contractual relationship with the card scheme, own their BIN ranges, and bear full settlement and compliance responsibility. Affiliate members – also called associate members – operate under a principal member’s umbrella, accessing the scheme through that principal’s BIN without holding a direct scheme relationship themselves. The distinction defines the compliance hierarchy, the settlement chain, and ultimately who is accountable to Visa or Mastercard for every transaction on a programme.

On this page:

What can a principal member do that an affiliate member cannot?

Answer

A principal member can own BINs, settle transactions directly with the scheme, sponsor other businesses as affiliate members, and acquire merchants. An affiliate member can issue cards and process transactions, but cannot own BINs, cannot settle directly with the scheme, and cannot sponsor other businesses to issue cards.

The principal member’s position in the hierarchy

Principal members sit at the top of the card scheme membership hierarchy. They hold a direct contractual relationship with Visa or Mastercard, are assigned BIN ranges by the scheme, and are directly accountable to the scheme for compliance across all cards and transactions associated with their BINs. That accountability extends to any affiliate members operating under their sponsorship – a principal member is responsible for the conduct of the programmes it sponsors.

This means principal members carry both significant operational capability and significant liability. They can build and run card programmes at scale without depending on any other institution. They can also generate revenue by sponsoring others. But they bear the full weight of scheme compliance, settlement exposure, and scheme fees directly.

What affiliate members can and cannot do

Affiliate members – registered with the scheme under a principal member’s sponsorship – can issue branded payment cards and process cardholder transactions. They have a scheme registration, which is real and meaningful: their programmes are recognised by the scheme and transactions flow legitimately through the network.

What they cannot do is operate independently of their sponsor. They cannot settle directly with the scheme – settlement flows through the principal member. They cannot hold BINs in their own name. They cannot sponsor other businesses. And if their principal sponsor ceases to operate or terminates the relationship, their card programme ceases with it until a new sponsor is found.

What to watch for

  • When evaluating a BIN sponsor, confirm they hold principal membership – not affiliate or associate membership – of the relevant scheme. An affiliate cannot legitimately sponsor other businesses to issue cards under a BIN it does not own.
  • Some consultancies and intermediaries position themselves as programme managers without clarifying their actual scheme membership status. Always ask to see the scheme membership confirmation directly.

What are the eligibility requirements for principal membership?

Answer

To become a principal member of Visa or Mastercard in Europe, a business must hold a regulatory licence – either an Electronic Money Institution (EMI) licence or a banking licence – issued by a recognised European financial regulator. The scheme will also assess the applicant’s financial standing, operational infrastructure, compliance framework, and the viability of the proposed programme.

The regulatory prerequisite

A Payment Institution (PI) or Electronic Money Institution (EMI) licence is a prerequisite for any card scheme principal membership application in Europe. The FCA in the UK and the Bank of Lithuania are the two most commonly used licensing authorities for European card programme operators. Obtaining the licence typically takes 12 to 18 months on its own, before scheme membership applications begin.

What the schemes assess

Unlike a financial regulator, the card schemes take a product-first approach to membership applications. They want to understand what the business does, how it will use scheme membership, and whether the risks it introduces are acceptable to the network. The application requires detailed documentation covering:

  • Business model and proposed programme design
  • Financial statements and capital adequacy
  • Compliance framework including AML, KYC and fraud controls
  • Technical infrastructure for card issuing and transaction processing
  • Settlement and liquidity capability
  • Governance and key personnel

Applications are not purely pass/fail assessments – they involve ongoing dialogue with the scheme’s membership team. Knowing how to position the application and how to respond to queries materially affects both the outcome and the timeline.

What to watch for

  • Scheme membership applications run in parallel to, not instead of, regulatory licensing. Both are required and both take time. Plan for a combined timeline of 18 to 36 months from a standing start.
  • The schemes have discretion in accepting members and can decline applications without detailed explanation. Prior scheme experience, a credible compliance track record, and a clearly defined programme are material to the outcome.
  • Mastercard and Visa have different fee structures and, to some degree, different programme requirements. Most European card issuers pursue both, but the applications are separate and the timelines may differ.

What does it cost to become a principal member?

Answer

Principal membership involves both one-time application and setup costs and ongoing annual fees. Total first-year costs for a UK or European project are typically in the low to mid six figures per scheme, with significant variation depending on programme type, geography, and whether the applicant is pursuing issuing, acquiring or both.

The cost components

Scheme costs for principal membership cover several categories. Application fees are payable at submission and are non-refundable regardless of outcome. BIN registration fees are paid when BINs are assigned. Ongoing membership fees are levied annually and are typically tiered by transaction volume. Settlement fees apply per transaction processed through the scheme’s network.

These are the direct scheme costs. The indirect costs – internal resource, technology build or integration, legal and compliance advisory, and the ongoing operational overhead of maintaining scheme compliance – typically exceed the direct scheme fees for most applicants.

Why Mastercard is generally less expensive than Visa in Europe

This is a well-documented pattern in the European market. Mastercard’s membership fee structure for European applicants is generally lower than Visa’s, particularly for issuers at lower transaction volumes. For businesses pursuing both, the gap in total first-year cost can be material. This difference narrows significantly at higher volumes where scheme incentive programmes and volume discounts become relevant.

What to watch for

  • Published fee information from the schemes is limited. Budget figures from advisers who have recently completed membership applications are more reliable than public estimates, which date quickly.
  • The cost of maintaining principal membership – ongoing fees, compliance resource, scheme audits, rule change implementation – often exceeds the initial setup cost within three to four years. Model the total cost of ownership, not just the entry cost.
  • For most fintechs at early or mid-scale, the economics of BIN sponsorship remain more favourable than principal membership until transaction volumes and programme complexity justify the overhead of direct membership.

Who holds settlement responsibility in each membership model?

Answer

In a principal membership model, the principal member settles directly with the card scheme – they hold the settlement account with the scheme and bear the liquidity and counterparty risk of settlement. In an affiliate model, settlement flows through the principal member: the scheme settles with the principal, who then settles with the affiliate. The affiliate does not have a direct settlement relationship with the scheme.

Why settlement responsibility matters operationally

Settlement timing, settlement currency, and the handling of failed settlements are all governed by the principal member in an affiliate arrangement. The affiliate’s settlement terms are set by the programme agreement with the principal – they are not directly negotiable with the scheme. This means the affiliate is exposed not only to its own settlement performance but to the principal’s financial standing and operational reliability.

This is one of the most significant risk factors in choosing a BIN sponsor. A principal member that encounters financial difficulty – even temporarily – can create settlement delays or failures that cascade to all affiliated programmes running under its BINs, regardless of the individual affiliate’s own financial health.

Settlement currencies and multi-market implications

Principal members settle in the currencies supported by their scheme membership and their settlement banking arrangements. For programmes operating across multiple European markets, the principal’s settlement currency coverage directly determines what currencies the affiliate programme can support without additional FX conversion steps. A principal member with settlement capability in EUR, GBP, PLN, HUF and RON – as DiPocket provides – enables multi-currency programmes without the affiliate needing separate banking arrangements for each currency.

What to watch for

  • Ask your prospective BIN sponsor for their settlement banking arrangements and which currencies they settle in directly. Settlement via FX conversion introduces additional cost and timing risk.
  • Ask about the sponsor’s financial standing and capital adequacy. As an affiliate you are operationally exposed to their financial health in the settlement chain even though they are not your bank.
  • Understand the settlement cycle your programme will operate on – T+1, T+2 or other – and how failures or disputes in the settlement chain are handled under the programme agreement.

Can an affiliate member sponsor other businesses to issue cards?

Answer

No. Only principal members can sponsor other businesses as affiliate or associate members of a card scheme. An affiliate member does not own BINs and cannot grant access to a BIN it does not hold. Sub-sponsorship arrangements – where an affiliate purports to sponsor a third party – are not permitted under Visa or Mastercard’s rules.

Why this matters when evaluating infrastructure partners

The practical implication is straightforward: if you are evaluating a provider who claims to offer BIN sponsorship, that provider must be a principal member of the relevant scheme. An affiliate or associate member cannot legitimately act as a BIN sponsor regardless of how the commercial arrangement is described.

This is not a technicality – it is a scheme rule violation that can result in the termination of all programmes running under the relevant BIN. Due diligence on a prospective sponsor should confirm their principal membership status directly with the scheme’s member directory, not just from the provider’s own documentation.

What to watch for

  • Verify principal membership status directly through Visa’s or Mastercard’s member directories. These are accessible to businesses evaluating scheme participants and are more reliable than self-reported membership claims.
  • Be cautious about arrangements described as ‘programme management’ or ‘card issuing facilitation’ without explicit confirmation of the underlying principal membership that makes card issuance possible.

What is the difference between affiliate and associate membership?

Answer

The terminology varies between Visa and Mastercard. Visa uses ‘affiliate member’ and Mastercard uses ‘associate member’ to describe the same structural position: a business that issues cards under a principal member’s BIN, with a scheme registration but without a direct scheme contract. For practical purposes, affiliate and associate membership in a card scheme context are the same thing.

Why the terminology is inconsistent

Visa and Mastercard developed their membership frameworks independently and use different terminology throughout their rules and documentation. This creates terminology confusion in commercial discussions, particularly in multi-scheme programmes where a business may be described as a Visa affiliate and a Mastercard associate simultaneously, despite holding structurally identical positions in each network.

Some advisers and providers use ‘associate member’ as a generic term covering any non-principal participant, including those with more limited access than a full affiliate. In scheme documentation, the specific capabilities and obligations attached to each membership tier are what matter – the label alone does not determine what a member can do.

 

Membership terminology across schemes at a glance

Position Visa terminology Mastercard terminology
Direct scheme member with BIN ownership Principal member Principal member
Sponsored member operating under a principal’s BIN Affiliate member Associate member
Programme manager without direct scheme registration Third party agent / TPP Third party processor / TPP

 

What to watch for

  • When reviewing a programme agreement or scheme documentation, do not assume the same term means the same thing across Visa and Mastercard materials. Check the specific capabilities and obligations defined for the membership tier in each scheme’s rules.

How does the principal member’s scheme membership affect the programmes built on top of it?

Answer

A principal member’s scheme membership scope – which schemes, which geographies, which card types – sets the ceiling for every affiliate programme running under it. An affiliate cannot operate in a market the principal is not authorised for, cannot issue on a scheme the principal is not a member of, and cannot access card products or programme features the principal has not enabled within their own membership.

Geographic reach

A principal member’s scheme membership is granted for specific geographies. In Europe, a principal member authorised in one EEA jurisdiction can typically passport their scheme membership across EEA markets, but this requires the regulatory authorisation to operate in those markets as well as the scheme membership itself. For an affiliate, the operational footprint is bounded by wherever the principal can legitimately operate.

This is why a principal member’s European footprint – not just their membership status – is a meaningful evaluation criterion. A sponsor with Visa and Mastercard principal membership but regulatory authorisation only in one jurisdiction cannot legitimately support a multi-market programme in the same way that a dual-regulated sponsor with established operations across 15 markets can.

Scheme and card product access

Not all principal members hold membership of both Visa and Mastercard. A principal that is a Visa member only cannot sponsor a Mastercard programme, and vice versa. For businesses that want the flexibility to issue on either scheme – or to run both Visa and Mastercard programmes simultaneously – dual membership of the sponsor is a prerequisite, not a preference.

Similarly, access to specific card product types – virtual cards, tokenised cards for mobile wallets, commercial card products, prepaid – depends on the principal member having those features enabled within their own membership. An affiliate cannot access programme features the principal has not activated.

What to watch for

  • Confirm your prospective sponsor holds principal membership of both Visa and Mastercard if you want programme flexibility or dual-scheme issuance. Single-scheme membership limits your options at launch and reduces leverage if commercial terms with one scheme change.
  • Ask specifically about tokenisation support (Apple Pay, Google Pay compatibility) – this requires the principal to have activated token service provider arrangements within their membership. It is not automatically available.
  • For multi-market programmes, ask the sponsor to confirm their regulatory authorisation on a market-by-market basis, not just their scheme membership. The two are independent requirements and gaps in either will prevent launch in that market.

When does it make sense to move from affiliate to principal membership?

Answer

Moving from affiliate to principal membership makes sense when the cost of ongoing BIN sponsorship fees exceeds the cost of running direct membership at your transaction volume, when you need programme features or geographies your current sponsor cannot provide, when your risk profile requires the independence of owning your own BINs, or when you want the ability to sponsor other businesses yourself.

The economics threshold

At sufficiently high transaction volumes, the per-transaction scheme fees paid through a BIN sponsor’s margin become more expensive than the direct scheme fees a principal member would pay. The crossover point varies by programme type, transaction mix and the sponsor’s fee structure, but for most European card programmes it falls somewhere in the range of several million transactions per year. Below that threshold, the overhead of principal membership – fee base, compliance resource, operational investment – is unlikely to be justified on economics alone.

The control and independence argument

Beyond economics, some businesses pursue principal membership for strategic reasons: full control over the scheme relationship, the ability to negotiate directly with Visa and Mastercard on programme terms, independence from a third party’s financial health in the settlement chain, and the credibility that direct membership confers in certain commercial contexts. These are legitimate reasons to pursue direct membership at a scale where the economics are marginal.

Planning the transition

Moving from affiliate to principal membership involves re-registering active card programmes with the scheme under the new principal’s BINs, which typically requires re-issuing physical cards to existing cardholders and updating card-on-file registrations. This is operationally significant and should be planned well in advance. A BIN sponsor who has helped clients through this transition – and who has an interest in supporting it rather than obstructing it – is a meaningfully better long-term partner than one who does not.

What to watch for

  • Model the full cost of principal membership before deciding it is economically justified – include compliance resource, technology investment, scheme audit costs and the ongoing operational overhead, not just direct scheme fees.
  • Discuss the transition pathway explicitly with your BIN sponsor before signing. A sponsor who actively supports and plans for eventual principal membership is a better long-term partner than one who treats it as a competitive threat.
  • The timeline from deciding to pursue principal membership to live operation is typically 18 to 36 months. Factor this into your programme roadmap if you are building toward eventual direct membership.

Evaluating your route to card scheme access? works?

DiPocket holds principal membership of both Visa and Mastercard and has supported fintechs, PSPs and non-financial businesses through every stage of the card programme journey – from affiliate launch to principal membership transition. Explore our BIN sponsorship service or read the full guide: BIN sponsorship explained.

What is the difference between a BIN sponsor and an issuer processor?

What is a BIN in payment card issuing

A BIN sponsor provides the regulatory and scheme infrastructure that makes card issuance legally possible: principal membership of a card scheme, a licensed BIN, and accountability to Visa or Mastercard for scheme compliance. An issuer processor provides the technology infrastructure that makes transactions work in real time: authorisation, clearing, settlement messaging, card lifecycle management, and spend control enforcement. The two roles are structurally distinct and governed by separate contractual relationships – but they are frequently provided by the same entity, which has significant implications for programme flexibility and negotiating leverage.

On this page:

What does a BIN sponsor do?

Answer

A BIN sponsor provides the regulatory and scheme-level infrastructure that makes card issuance possible. Specifically: they hold principal membership of a card scheme, own or control the BINs used by client programmes, register client programmes as affiliate members of the scheme, bear accountability to Visa or Mastercard for compliance across all cards issued under their BINs, and provide the settlement infrastructure through which card transactions are cleared and funds move.

The regulatory dimension

A BIN sponsor must hold a regulatory licence – typically an Electronic Money Institution (EMI) licence or banking licence – issued by a recognised financial regulator. In Europe, this is a prerequisite for principal scheme membership and for operating any card issuance activity. The sponsor is the regulated entity in the programme: it is accountable to the regulator and to the card scheme for the conduct of all cards issued under its BINs, regardless of how many client programmes are running beneath it.

This is not a passive role. The sponsor must maintain active oversight of the compliance standards of all affiliated programmes, approve programme design and marketing materials, and ensure that AML and KYC standards are met consistently across all clients. A sponsor that takes a light-touch approach to these obligations is a compliance risk for client programmes – not just for itself.

The scheme dimension

The BIN sponsor’s scheme membership determines what the client programme can access: which networks (Visa, Mastercard or both), which geographies, which card product types, and which programme features. The sponsor negotiates directly with the schemes on fees, programme parameters, and product access. Clients benefit from the sponsor’s commercial relationships with the schemes but do not have a direct voice in those negotiations.

What to watch for

  • Confirm the sponsor holds principal membership – not affiliate membership – of the relevant scheme. Only principal members can legitimately sponsor client programmes.
  • Ask specifically about the sponsor’s oversight model: how do they monitor the compliance of client programmes on an ongoing basis? A sponsor with weak oversight processes creates scheme compliance exposure for all programmes under its BINs.

What does an issuer processor do?

Answer

An issuer processor provides the transaction technology infrastructure that connects the card programme to the scheme network and handles the real-time mechanics of every card transaction. This includes authorisation processing, clearing and settlement messaging, card lifecycle management (issuance, activation, blocking, replacement), spend control enforcement, and the data feeds that drive programme reporting and reconciliation.

The authorisation function

When a cardholder presents a card, the transaction request arrives at the issuer processor’s authorisation platform within milliseconds. The platform applies the programme’s configured rules – spend controls, fraud logic, account status checks – and returns an approval or decline to the card scheme’s network before the cardholder’s card reader has finished processing. The speed, reliability and configurability of this function directly determines the cardholder experience and the programme’s operational performance.

Card lifecycle and scheme connectivity

Beyond real-time authorisation, the issuer processor manages the full card lifecycle: issuing card numbers and PINs, managing tokenisation for mobile wallets (Apple Pay, Google Pay), processing card replacements and blocks, and handling dispute and chargeback workflows in line with scheme rules. They also maintain the technical connectivity to the scheme’s network infrastructure and are responsible for implementing scheme rule changes and technical updates as they are released by Visa and Mastercard.

Key European issuer processors

The European issuer processing market is served by a relatively small number of specialist providers. Thredd (formerly GPS) is one of the largest and most widely used. Others operating in this space include Marqeta, Nuvei, and various providers that have expanded into processing from adjacent positions in the payments stack. The processor a programme runs on matters commercially as well as technically – fee structures, transaction volume thresholds, and product capability vary materially between providers.

What to watch for

  • Processor capability is programme-specific, not generic. A processor that works well for a high-volume consumer prepaid programme may not be the right fit for a low-volume B2B virtual card programme with complex spend control requirements. Evaluate fit for your specific use case.
  • Ask about the processor’s scheme certification status. Processors must be certified by Visa and Mastercard to process on their networks, and certifications have scope limits. Confirm the processor is certified for the card types and geographies your programme requires.

Who is accountable for regulatory compliance in a card programme?

Answer

The BIN sponsor – as the regulated entity and scheme principal member – holds ultimate accountability for regulatory compliance in a card programme. The issuer processor operates a compliant technical environment (PCI DSS, scheme technical rules) but regulatory accountability under frameworks such as PSD2 and AML legislation rests with the licensed entity, which is the sponsor.

The compliance division in practice

The regulatory compliance picture in a card programme involves three overlapping layers, and the distinction between them matters:

  • Scheme compliance – adherence to Visa and Mastercard’s operating rules. Accountability sits with the principal member (the BIN sponsor). The processor supports this by implementing scheme rule updates in their technical platform, but the sponsor is accountable to the scheme.
  • Regulatory compliance – adherence to financial regulation (PSD2, AML Directives, data protection). Accountability sits with the licensed entity – again the sponsor, as the EMI or bank. The processor is not regulated as a financial institution and does not carry this accountability.
  • Technical compliance – PCI DSS and scheme technical standards for data security and transaction processing. This is primarily the processor’s domain: they operate the environment in which card data is handled and are responsible for maintaining the certifications that cover that environment.

A card programme therefore has two separately accountable compliance parties: the sponsor for regulatory and scheme-rule accountability, and the processor for technical security compliance. This distinction matters when reviewing programme agreements – the allocation of compliance obligations, indemnities, and incident response responsibilities should reflect this division explicitly.

What to watch for

  • Do not assume that because a processor operates a PCI DSS-certified environment, the programme is fully covered from a regulatory compliance standpoint. PCI DSS is a data security standard, not a regulatory compliance framework.
  • In the programme agreement with your BIN sponsor, check how compliance obligations are allocated between the sponsor, the processor and your own business. Ambiguity in this allocation creates risk that will only become visible when something goes wrong.

What happens when one provider offers both roles?

Answer

When a single provider acts as both BIN sponsor and issuer processor – often described as a fully integrated or turnkey card programme platform – the client has one commercial relationship, one contract, and one point of accountability. This simplifies launch and reduces integration complexity. The trade-off is reduced flexibility: switching either the sponsor or the processor relationship means switching both, because they are contractually and technically bundled.

The case for integrated providers

For most businesses launching their first card programme, an integrated provider offering both BIN sponsorship and issuer processing is a sensible starting point. The integration between the two functions is already built, scheme and regulatory compliance is coordinated by one team, and time to market is faster than assembling separate relationships. The operational burden of managing two vendor relationships is also reduced.

DiPocket provides both BIN sponsorship and processing infrastructure, working with multiple issuer processors – including Thredd – to give clients flexibility in their processing arrangement while maintaining a single point of accountability for scheme compliance and regulatory oversight.

The processor flexibility question

The critical question with any integrated provider is not whether they bundle both roles, but whether their processing arrangement is fixed or flexible. Some integrated providers are tied to a single processor: the BIN sponsorship and the processing are offered as a single indivisible product, and the client has no ability to use a different processor. Others, like DiPocket, operate with multiple processors and allow the processing component to be selected or changed based on the client’s requirements.

Processor lock-in has operational consequences that only become visible as a programme grows. If the bundled processor cannot support a new geography, a higher transaction volume, or a specific technical requirement, the client has no recourse short of migrating the entire programme to a new provider – including re-issuing cards to existing cardholders.

What to watch for

  • When evaluating an integrated provider, ask explicitly: are the BIN sponsorship and processing components separable? Can you change the processor without changing the BIN sponsor? The answer to these questions determines your long-term flexibility.
  • Ask which processors the sponsor works with and whether you can specify or influence the choice. A sponsor who works with multiple processors and is transparent about the options is materially better positioned to support a growing programme than one who cannot answer the question.

What is a programme manager, and how does it relate to these two roles?

Answer

A programme manager is an entity that takes operational responsibility for running a card programme on behalf of the client – coordinating between the BIN sponsor, the issuer processor, the card bureau, and other service providers. A programme manager does not need to hold a regulatory licence or scheme membership themselves. They act as the operational layer above the infrastructure, not as part of it.

Where the programme manager sits

In a card programme with all roles separated, the structure typically looks like this: the BIN sponsor provides regulatory and scheme access; the issuer processor handles transaction technology; and the programme manager coordinates the operational delivery – onboarding, card management, dispute handling, reporting, and day-to-day scheme rule compliance on behalf of the client. The client sits above all of these.

In an integrated provider model, the sponsor often also acts as the programme manager, handling operational coordination as part of the service. This is the model DiPocket operates: the BIN sponsorship, operational oversight, and programme support functions are provided by the same entity.

Why the distinction matters

Some providers in the market describe themselves as programme managers or card programme platforms without being the BIN sponsor themselves – they are sitting above a sponsor and a processor without holding the scheme membership or regulatory licence that underpins the whole arrangement. This creates a longer chain of dependency and an additional potential failure point. If the provider’s relationship with the underlying sponsor breaks down, every programme running on the platform is affected.

What to watch for

  • If a provider describes themselves as a programme manager, ask directly: who is the BIN sponsor, and do they hold principal scheme membership? The answer tells you where the regulatory and scheme accountability actually sits.
  • The longer the chain between your programme and the regulated entity, the more dependency risk you carry. Ideally the BIN sponsor, the regulatory licence holder, and the scheme principal member are the same entity.

Can you switch issuer processor without changing BIN sponsor?

Answer

In principle yes, but in practice it depends entirely on the contractual and technical architecture of your current arrangement. If the BIN sponsor and issuer processor are separate providers with separate agreements, processor migration is technically possible without changing the sponsor relationship. If the two are contractually bundled, changing the processor means changing the sponsor – and everything that entails.

What processor migration actually involves

Even where processor and sponsor relationships are technically separable, migrating an issuer processor is a significant technical project. The new processor needs to be integrated with the sponsor’s settlement infrastructure, scheme registrations need to be updated to reflect the new processor, and the card programme’s transaction processing logic needs to be re-implemented and tested on the new platform. Active cardholders are typically not affected – card numbers and PANs do not change when a processor changes, because the PAN is associated with the BIN and the account, not with the processor.

When processor migration is worth considering

Processor migration becomes relevant when the current processor cannot support a new requirement – a new geography, a higher transaction volume tier, a specific spend control feature, or better pricing at scale. It is also relevant when a programme migrates to a new BIN sponsor who uses a different processor. In either case, the commercial benefits need to outweigh the migration cost and operational disruption, which is non-trivial for active programmes.

What to watch for

  • Before signing with any BIN sponsor, confirm in writing whether you have the contractual right to change issuer processor independently of the sponsor relationship. If the agreement is silent or ambiguous on this point, assume it is not permitted.
  • Processor migration for an active programme with cardholders takes months, not weeks. If your programme is growing and you anticipate needing to change processor, plan the migration well before the need becomes urgent.

Can you switch BIN sponsor without changing issuer processor?

Answer

Switching BIN sponsor is operationally more disruptive than switching issuer processor. A sponsor change typically requires re-registration of the programme with the card scheme under the new sponsor’s BINs, which means issuing new card numbers to existing cardholders – because the BIN prefix changes. This is the most operationally significant aspect of any programme migration.

What a sponsor migration actually involves

When a programme moves to a new BIN sponsor, the cards in existing cardholders’ hands carry the old sponsor’s BIN. Those cards cannot simply be reassigned to a new BIN – the card number incorporates the BIN prefix and cannot be changed without physical or virtual card replacement. This means all active cardholders need to be re-issued new cards, all card-on-file registrations (subscriptions, saved payment methods) need to be updated, and the programme needs to operate on both old and new BINs simultaneously during a transition period.

This is the most frequently cited reason why businesses stay with a sub-optimal BIN sponsor longer than they should – the cost and complexity of migration is significant, and underestimated at the time the original sponsor relationship was established.

Whether the existing processor can be retained

In some cases, the new BIN sponsor will work with the same issuer processor as the old one, allowing the programme to migrate the sponsor relationship without also migrating the processing infrastructure. Whether this is possible depends on the new sponsor’s processing relationships and the technical architecture of the existing programme. Where it is possible, it materially reduces migration complexity.

What to watch for

  • When selecting a BIN sponsor, think explicitly about the migration scenario. How would you exit this relationship if needed, and what would the cardholder impact be? A sponsor who has managed client migrations – and who can describe how they approach them – understands the risk they are asking you to accept.
  • Build a cardholder re-issuance cost estimate into any programme migration business case. For programmes with tens of thousands of active cardholders, card replacement logistics alone represent a material cost and operational project.

What should you ask when evaluating a provider that bundles both roles?

Answer

The core questions to ask a provider that offers both BIN sponsorship and issuer processing are: whether the two components are contractually separable, which processors they work with and whether you can specify or change the processor, what their authorisation performance and uptime data looks like, how they handle a client that needs to migrate to a different processor or direct scheme membership, and what their financial standing and regulatory compliance track record is.

The separation question

Ask directly: if I need to change processors in two years because my volume has grown or my requirements have changed, can I do that without changing BIN sponsor? A provider who cannot answer this question clearly, or who answers it with a commercial deflection rather than a structural explanation, is signalling that the two components are effectively locked together.

Performance and stability

For the processing component, ask for authorisation uptime SLA data and historical authorisation rate performance across programmes comparable to yours. Uptime SLAs below 99.9% for the authorisation platform are a concern for any programme where card acceptance reliability matters to the cardholder experience. Authorisation rate performance tells you how effectively the platform converts legitimate transaction attempts into approvals.

For the sponsorship component, ask about the provider’s financial standing, regulatory audit history, and how they have handled compliance incidents or scheme rule changes across their client portfolio. A sponsor who has been operating for a decade and has navigated multiple regulatory changes is materially more credible than one who cannot speak to their history.

BIN sponsor vs issuer processor: roles at a glance

 

Dimension BIN sponsor Issuer processor
Primary function Regulatory and scheme access Transaction technology
Licence required EMI or banking licence Scheme processor certification
Scheme relationship Principal member – direct Certified processor – technical
BIN ownership Yes – owns or controls BINs No – operates within sponsor’s BINs
Settlement accountability Yes – settles with scheme No – supports settlement data
Regulatory accountability Yes – PSD2, AML, scheme rules No – technical standards only (PCI DSS)
Real-time authorisation No (unless also the processor) Yes – core function
Spend controls Defines permitted parameters Enforces in real time
Can be changed independently Only if not contractually bundled Only if not contractually bundled

 

What to watch for

  • Ask for the provider’s authorisation uptime SLA in writing, and ask for historical performance data. Claims of high uptime without supporting data should not be taken on trust for a function this operationally critical.
  • Ask how the provider has handled clients that outgrew the bundled arrangement and needed to move to direct scheme membership or a different processor. Their answer tells you whether they see themselves as a long-term partner or a fixed-term infrastructure contract.

Questions about how DiPocket’s BIN sponsorship and processing infrastructure works?

DiPocket provides BIN sponsorship with processor flexibility – working with multiple issuer processors including Thredd so that clients are not locked into a single processing arrangement as their programme grows. Explore our BIN sponsorship service.

What is a BIN in payment card issuing?

What is a BIN in payment card issuing

A Bank Identification Number (BIN) is the first six to eight digits of a payment card number. These digits identify the institution that issued the card and determine how the transaction is routed through the card scheme network. In payment card issuing, the BIN is the foundational identifier that connects every card transaction back to the issuing institution – and in BIN sponsorship arrangements, back to the regulated entity that holds scheme membership on the client’s behalf.

On this page:

What does BIN stand for, and is it the same as IIN?

Answer

BIN stands for Bank Identification Number. IIN stands for Issuer Identification Number. They refer to the same digits on a payment card. BIN is the older and more widely used term; IIN is the technically correct modern term.

Why the terminology changed

The term BIN dates from an era when only banks issued payment cards. As non-bank entities – including fintechs, electronic money institutions and payment service providers – began issuing cards under their own brands, the term Bank Identification Number became a misnomer. ISO updated its standard (ISO/IEC 7812) to use Issuer Identification Number as the official term, reflecting the reality that the issuing institution is not always a bank.

In practice, the industry continues to use BIN almost universally. Both terms appear in scheme documentation, processor agreements and commercial conversations. For fintechs and PSPs working with a BIN sponsor in Europe, the sponsor is the regulated issuer whose BIN appears on the cards – whether that sponsor is a bank or, as is common in the EU, an authorised electronic money institution.

What to watch for

  • Agreements and scheme documentation may use BIN and IIN interchangeably – treat them as the same thing.
  • Some processors use IIN in their technical documentation even when the commercial term used is BIN.

How many digits is a BIN, and why did it change from six to eight?

Answer

A BIN is six to eight digits. The expansion from six to eight digits was mandated by Visa and Mastercard in April 2022 in response to a projected shortage of available six-digit combinations caused by the rapid growth in the number of payment card-issuing institutions globally.

Why the expansion happened

Six-digit BINs support a finite number of unique combinations. As the number of card-issuing institutions grew, driven in part by the expansion of fintech payment card issuing under BIN sponsorship arrangements, ISO projected that the supply of available six-digit BINs would be exhausted. ISO/IEC 7812-1 was revised in 2017 to extend the standard from six to eight digits, and Visa and Mastercard required all acquirers and processors to accommodate eight-digit BINs by April 2022.

An eight-digit BIN creates a sufficiently large namespace to accommodate continued issuance growth well into the future. The expansion did not change card numbers themselves, as PANs remained the same total length. Only the portion classified as the BIN grew.

What this means in practice for payment card programmes

All new BINs assigned by Visa and Mastercard since April 2022 are eight digits. Existing six-digit BINs continued in use during a transition period. For a business launching a new card programme today, its BIN will be eight digits.

What to watch for

  • If you are migrating an existing payment card programme, confirm whether your current BIN is six or eight digits.
  • The expansion of the BIN did not change the total length of the Primary Account Number (PAN) – the card number itself remains the same length.

What information does a BIN contain?

Answer

A BIN identifies the payment card scheme (Visa, Mastercard and so on), the issuing institution, the card type (credit, debit, prepaid), and in some cases the country of issuance and card product level. It does not contain any personal data about the cardholder.

Breaking down what the digits tell you

The first digit of a BIN is called the Major Industry Identifier (MII). It identifies the broad category of the issuing institution. For payment cards, Visa cards typically start with 4 and Mastercard cards with 5 (or 2 for newer Mastercard ranges). The remaining digits identify the specific issuing institution and, within that, the card product type.

For a fintech or PSP operating under BIN sponsorship, the BIN identifies the sponsor – the regulated EMI or bank that holds scheme membership – not the client business whose brand appears on the card. This is an important distinction: the cardholder’s card carries the client’s brand, but the BIN resolves to the sponsor.

What a BIN does not reveal

A BIN does not contain or expose any cardholder personal data. It does not identify the individual account, the cardholder’s name, their account balance, or any transaction history. It identifies the institution and the card product type only. The individual account is identified by the digits that follow the BIN within the full PAN.

In a BIN sponsorship arrangement, the authorisation of every card transaction flows through the sponsor’s infrastructure, not directly through the client’s systems. The sponsor’s authorisation platform handles real-time approval decisions, applies programme-level spend controls, and passes settlement data back to the client. Understanding this is material to programme design, performance expectations, and risk allocation.

Where the sponsor sits in the authorisation chain

When a cardholder presents a card, the transaction is routed to the issuing institution identified by the BIN – which in a sponsored programme is the sponsor, not the client. The sponsor’s authorisation platform applies the card’s spend rules, fraud logic and account status checks before returning an approval or decline. The client’s brand is on the card, but the sponsor’s infrastructure is making the authorisation decision.

This is why the sponsor’s authorisation infrastructure – its uptime, its authorisation rate performance, its real-time fraud capability – should be treated as a core evaluation criterion, not a technical detail. A sponsor with weak infrastructure will generate avoidable declines and cardholder friction regardless of how well the programme is designed.

What to watch for

  • Ask your prospective sponsor for their authorisation uptime SLA and historical authorisation rate data across programmes similar to yours. These are material commercial metrics, not technical footnotes.
  • Understand which spend control parameters are configurable by you in real time versus those that require a change request to the sponsor. Real-time configurability matters for programmes with dynamic or recipient-specific rules.
  • Ask whether the sponsor operates their own authorisation platform or relies on a third-party processor for authorisation decisions. Each additional intermediary is a potential point of latency or failure.
  • Spend controls configured at programme level – such as merchant category restrictions or per-transaction limits – are applied during the authorisation step by the issuing institution. Understanding where these controls are applied is important when designing your card programme.
  • Transaction decline rates and authorisation performance depend on the sponsor’s processing infrastructure as well as the card scheme’s network. Ask about authorisation rates and uptime guarantees when evaluating a BIN sponsor.

How does a BIN work during a payment card transaction?

Answer

In a BIN sponsorship arrangement, the authorisation of every payment card transaction flows through the sponsor’s infrastructure, not directly through the client’s systems. The sponsor’s authorisation platform handles real-time approval decisions, applies programme-level spend controls, and passes settlement data back to the client. Understanding this is material to programme design, performance expectations, and risk allocation.

Where the sponsor sits in the authorisation chain

When a cardholder presents a card, the transaction is routed to the issuing institution identified by the BIN – which in a sponsored programme is the sponsor, not the client. The sponsor’s authorisation platform applies the card’s spend rules, fraud logic and account status checks before returning an approval or decline. The client’s brand is on the payment card, but the sponsor’s infrastructure is making the authorisation decision.

This is why the sponsor’s authorisation infrastructure – its uptime, its authorisation rate performance, its real-time fraud capability – should be treated as a core evaluation criterion, not a technical detail. A sponsor with weak infrastructure will generate avoidable declines and cardholder friction regardless of how well the programme is designed.

Where spend controls are applied

Spend controls – merchant category restrictions, per-transaction limits, geography locks, time-of-day rules – are configured at programme level and applied by the sponsor’s platform during the authorisation step. If a transaction does not match the configured rules, it is declined at authorisation before it reaches settlement. This means the reliability and granularity of the sponsor’s spend control capability directly determines how precisely you can govern cardholder behaviour in real time.

What to watch for

  • Ask your prospective sponsor for their authorisation uptime SLA and historical authorisation rate data across programmes similar to yours. These are material commercial metrics, not technical footnotes.
  • Understand which spend control parameters are configurable by you in real time versus those that require a change request to the sponsor. Real-time configurability matters for programmes with dynamic or recipient-specific rules.

Ask whether the sponsor operates their own authorisation platform or relies on a third-party processor for authorisation decisions. Each additional intermediary is a potential point of latency or failure.

Who assigns and owns a BIN?

Answer

BINs are assigned by the payment card schemes – Visa and Mastercard – to regulated issuing institutions that hold principal membership of the scheme. A BIN is the property of the scheme and the issuing institution. A fintech or PSP operating under BIN sponsorship does not own or hold a BIN directly; they operate within a BIN or BIN range assigned to their sponsor.

How BINs are assigned in practice

When a regulated institution such as an Electronic Money Institution becomes a principal member of Visa or Mastercard, it applies to the scheme for one or more BINs. The scheme assigns BINs based on the institution’s programme requirements, card types and geographies. The institution then owns those BINs for the purposes of card issuance.

Under BIN sponsorship, the sponsor allocates a BIN or a BIN range to the client programme. The sponsor retains ownership and scheme-level accountability for the BIN. The client operates within the parameters set by the sponsor and the scheme.

Who holds the BIN in the EU

In the EU, BINs are held by institutions authorised to issue electronic money – typically Electronic Money Institutions (EMIs) or banks with scheme principal membership. The Bank of Lithuania and the FCA are the two primary regulatory authorities licensing EMIs in the EU and UK respectively. DiPocket holds BINs under its principal membership of both Visa and Mastercard, enabling it to sponsor programmes across 15 European markets.

What to watch for

  • If you are evaluating a BIN sponsor, confirm that the BINs they are offering are registered in their name with the scheme – not sub-leased from another institution. Each layer of intermediary adds complexity and potential risk.
  • The scheme’s own records are the authoritative source on BIN ownership. A legitimate sponsor will be transparent about their BIN holdings and scheme membership status.

What is the difference between a shared BIN and a dedicated BIN?

Answer

A shared BIN is one where multiple client programmes operate within the same BIN, distinguished by sub-ranges within the full card number. A dedicated BIN is one assigned exclusively to a single programme. Dedicated BINs offer greater control and isolation; shared BINs are faster and lower cost to access, particularly at launch.

Shared BINs

Under a shared BIN arrangement, multiple clients of the same sponsor operate using sub-ranges within a single BIN. The full card number (PAN) is unique to each card and each account, so there is no risk of account collision. However, the BIN itself resolves to the sponsor and is shared with other programmes.

The main practical risk of a shared BIN is that the conduct of other programmes sharing the same BIN can affect your programme. If another programme on the same BIN has elevated fraud rates, some merchants or acquirers may block the BIN entirely, which would affect all programmes using it. This is rare but has occurred.

Dedicated BINs

A dedicated BIN is assigned exclusively to one programme. It offers complete isolation from other programmes, full control over the BIN’s reputation, and the ability to configure scheme-level settings without affecting other clients. Dedicated BINs are standard for larger or more established programmes.

Dedicated BINs require a direct scheme registration and typically involve higher fees and longer setup timelines than shared BINs. For a business launching a card programme for the first time, starting on a shared BIN and migrating to a dedicated BIN as the programme grows is a common and sensible path.

Shared BIN vs dedicated BIN: how they compare

Factor Shared BIN Dedicated BIN
Time to launch Faster – sub-range allocation only Longer – scheme registration required
Cost Lower – no BIN registration fee Higher – scheme fees apply
Isolation Shared with other programmes Exclusive to your programme
Fraud risk exposure Other programmes on BIN can affect yours Fully isolated
Control Programme-level only Full BIN-level control
Best for Early-stage or lower-volume programmes Established or higher-risk programmes

What to watch for

  • Ask your BIN sponsor how they screen other programmes sharing a BIN and what their fraud monitoring capability is across shared BIN clients.
  • If you are considering a shared BIN arrangement, ask specifically which other types of programme share your BIN – a BIN shared with high-risk card products carries more exposure than one shared with low-risk corporate card programmes.
  • Migrating from a shared to a dedicated BIN later involves re-issuing cards to existing cardholders. Factor this into your programme roadmap if you expect to grow into a dedicated BIN.

How does a BIN relate to BIN sponsorship?

Answer

BIN sponsorship is the arrangement that allows a business to issue payment cards using a BIN it does not own. The sponsor – a regulated institution with scheme principal membership – grants the client access to its BIN, takes on scheme-level compliance responsibility, and enables the client to issue cards without holding direct scheme membership itself.

The BIN is the technical foundation of the sponsorship arrangement. Without a BIN, no card can be issued. Without a scheme member willing to sponsor access to that BIN, a business without principal membership cannot issue cards at all. BIN sponsorship is the commercial and regulatory mechanism that bridges those two realities.

For a full explanation of how BIN sponsorship works, who uses it, and what to look for in a provider, see the guide: BIN sponsorship explained: the complete guide for fintechs and PSPs.

What is a BIN range?

Answer

A BIN range is a subset of a full BIN, defining the specific sequence of card numbers that a programme can issue. A single eight-digit BIN can support up to ten million unique card numbers; a BIN range allocates a portion of that capacity to a specific programme or client.

How BIN ranges work in practice

When a BIN sponsor assigns capacity to a client programme, they typically allocate a BIN range rather than the full BIN. The BIN range defines the starting and ending card numbers within which the programme can issue cards. All card numbers within that range share the same BIN prefix and are identifiable as belonging to the same programme.

BIN ranges are particularly relevant under shared BIN arrangements, where the sponsor’s BIN is divided into ranges for multiple client programmes. Under a dedicated BIN arrangement, the entire BIN’s range is available to one programme, though it may be sub-divided further by card product type.

What to watch for

  • When assessing capacity for your programme, ask your sponsor how large the BIN range allocated to you is and whether it can be extended if your programme grows.
  • A BIN range that is too small for your projected cardholder base will require a range extension or BIN migration – both of which involve operational work. Agree expected cardholder volumes upfront.