EST · MMXXVI
Home/Services/Banking Payments Emi/PSP and acquiring agreement from a Cross-border Perspective
Banking, Payments & EMI Onboarding

PSP and acquiring agreement from a Cross-border Perspective

Psp and acquiring agreement from a Cross-border Perspective. Cross-border digital-asset legal counsel for business – licensing, disputes and structuring. Talk t

Operating a cross-border digital-asset business without a properly structured payment services agreement exposes the business to frozen fiat rails, enforcement notices and, in the worst case, the sudden collapse of the revenue channel that connects on-chain activity to the real economy. A PSP (payment service provider) agreement and an acquiring agreement (the contract under which a merchant accepts card or bank-transfer payments through an acquirer) are not generic commercial contracts. They are regulated instruments, and the cross-border dimension adds a layer of legal exposure that a single jurisdiction's counsel routinely misses. This page explains the regulated basis, the contracting process, the structural traps and the cross-border interaction that any operator handling fiat rails for digital-asset activity must understand before signing.

What is the regulated basis for PSP and acquiring agreements?

PSP and acquiring agreements are rooted in payment-services regulation, which in every major jurisdiction treats the intermediation of funds as a licensed activity. Under the EU's Payment Services Directive framework, a PSP must hold an authorisation from a national competent authority to provide payment initiation, account information, card-issuing or acquiring services. Under the UK's FCA regime, a comparable registration or authorisation applies. The same principle holds under MAS's Payment Services Act in Singapore, where acquiring services fall under the major-payment-institution licence tier. Across the UAE, ADGM/FSRA and VARA's transfer-and-settlement activity class both touch the fiat layer that underpins a digital-asset exchange or custodian's payment flows.

The contract itself – the PSP or acquiring agreement – is therefore not merely a commercial arrangement between two businesses. It is a regulated relationship, and the representations, warranties and termination rights embedded in it reflect the licensor's regulatory obligations. A crypto business that treats it as a standard vendor contract will almost certainly breach a material term within months.

The cross-border issue is immediate. A PSP licensed in one jurisdiction frequently restricts the agreement by geography, by asset class, or by the regulatory status of the counterparty. If the digital-asset operator is serving users in jurisdictions where crypto activity is restricted, the PSP will often invoke a prohibited-use or geographic-restriction clause. We have seen this trigger account closures, fund holds and six-figure chargebacks – all of which were entirely avoidable with proper contract review at the outset.

For a first read of whether your current PSP arrangement is fit for purpose, contact OBOLUS at info@oboluslaw.com. The process above describes the standard contractual structure. Your facts – your entity, your user base, the regulated activity on both sides – change the analysis materially. Map your options.

Which operators need a PSP agreement and which need an acquiring agreement?

The two instruments serve distinct commercial functions, and operators frequently conflate them with costly consequences. A PSP agreement governs the processing of payment transactions – the movement of fiat from a customer's bank account or card to the operator's account. An acquiring agreement, by contrast, governs the acceptance of card-scheme payments (Visa, Mastercard) through a licensed acquirer who settles net funds after interchange and scheme fees.

For a crypto exchange, both instruments are typically necessary. The PSP agreement covers bank-transfer onboarding – SEPA, SWIFT, Faster Payments – while the acquiring agreement covers card top-ups. The risk profile of each is different. Bank-transfer PSPs conduct AML and sanctions screening at the transaction level. Card acquirers apply scheme-level rules that classify crypto purchases as high-risk merchants, often requiring a higher rolling reserve, a longer settlement cycle and enhanced chargeback liability.

A token issuer running a public sale has a narrower need: it requires a PSP agreement covering subscription receipts, but acquiring is often out of scope because card schemes have historically restricted token-sale payments. A VASP (virtual asset service provider) operating a custody-only service may need neither, but its banking arrangement will impose equivalent restrictions in the account terms and conditions.

The operator profile determines which instrument to pursue, which licence to present, and how to structure the underlying entity to satisfy the PSP or acquirer's onboarding criteria. Getting this wrong at the outset means returning to the onboarding queue – often many months later – with a materially different structure.

How does the onboarding process for a crypto PSP actually work?

Onboarding to a PSP or acquirer as a digital-asset business follows a structured due-diligence process that is materially more intensive than standard merchant onboarding. The PSP must satisfy its own regulator that its clients are themselves compliant. That means the operator must demonstrate, at a minimum: its own regulatory status; its AML/KYC programme; its transaction-monitoring controls; and its ultimate beneficial ownership structure to the satisfaction of the PSP's compliance team.

In practice, the process moves through three phases. First, the operator submits a merchant-application pack that typically includes corporate documents, a business plan, a compliance policy pack and, for crypto operators, a description of the on-chain to fiat flow. Second, the PSP's compliance and risk teams conduct an enhanced due-diligence review. For digital-asset businesses this phase is longer than for standard merchants – in our practice, it frequently takes several weeks to several months depending on the PSP's internal queue and the complexity of the structure. Third, the PSP issues a term sheet that specifies the settlement currency, the rolling reserve percentage, the chargeback threshold and the geographic restrictions.

The term sheet is where most deals fail or where material exposure goes unreviewed. The rolling reserve – funds withheld by the PSP against chargebacks – can represent a significant percentage of monthly processing volume. Settlement cycles, charge-back liability caps, and the right to suspend or terminate with or without notice are the three clauses that most often destroy a crypto operator's working capital position. We review these before signature as a matter of course.

Jurisdiction matters here in a concrete way. A PSP licensed under the EU regime can passport its services across the EU/EEA under MiCA's companion payment-services passporting rules. A PSP licensed only in the UK by the FCA cannot automatically extend that passport to EU jurisdictions post-Brexit. An operator banking through a Singapore MAS-licensed PSP has a different coverage map than one using a Malta MFSA-regulated institution. Matching the PSP's licensed perimeter to the operator's user geography is the first structuring question.

What is the cross-border reality for digital-asset businesses seeking fiat rails?

The cross-border reality is that no single PSP agreement covers global fiat flows for a digital-asset business. The myth – and it persists even among experienced operators – is that a single offshore licence is enough to serve clients globally. It is not. The PSP agreement is bounded by the PSP's own licence, by card-scheme rules that are geographically tiered, and by the regulatory status of the counterparty in each jurisdiction where users reside.

In our cross-border practice, we see three structural failure modes repeatedly. First, an operator incorporated in a low-friction jurisdiction signs a PSP agreement without disclosing that it serves users in jurisdictions where the PSP's licence does not apply. The PSP discovers this during a periodic review and terminates. Second, an operator holds a VASP registration in one EU member state and assumes this satisfies a Singapore MAS-licensed PSP's "regulated counterparty" requirement. It does not – MAS requires counterpart compliance with the Payment Services Act or an equivalent regime that MAS has assessed. Third, an operator structures its entity in a jurisdiction with strong privacy protections and then cannot provide the UBO transparency that an EU- or UK-licensed PSP legally requires.

The solution is a jurisdiction matrix at the outset: map the entity structure, the PSP's licensed perimeter, the acquiring scheme rules and the user-geography to identify coverage gaps before onboarding begins. This is slower upfront but eliminates the catastrophic mid-operation loss of fiat rails.

If your payment rails are at risk or a PSP has indicated it may exit the relationship, write to OBOLUS at info@oboluslaw.com – a structural review can surface the issue and the route back before the termination notice arrives. Map your options.

How do AML obligations and the Travel Rule interact with PSP agreements?

AML compliance is a condition precedent to PSP onboarding, not a post-contractual obligation – and the Travel Rule (the obligation under FATF Recommendation 15 to pass originator and beneficiary data with a virtual-asset transfer) has become a direct onboarding gate. PSPs and acquirers licensed in MiCA-aligned, MAS or FCA-supervised regimes now routinely require evidence of Travel Rule compliance before executing an agreement with a VASP counterparty.

The practical implication is significant. A crypto exchange that cannot demonstrate a functioning Travel Rule solution – meaning a VASP-to-VASP data-passing protocol aligned with the relevant jurisdiction's implementation – will be deprioritised or rejected in the PSP onboarding queue. This is not a theoretical risk. Regulators including ESMA and the FCA have signalled that PSPs bear responsibility for the compliance posture of their crypto-business clients, and PSP compliance teams act accordingly.

For the operator, this means the AML programme must be documented, the Travel Rule solution must be operational, and the transaction-monitoring configuration must be defensible before the PSP application is submitted. Submitting with a gap and expecting to resolve it during the review period is a common mistake. PSPs routinely decline rather than condition – the queue is long and the risk appetite is limited.

The cross-border dimension compounds this. The Travel Rule threshold and the required data fields vary by jurisdiction. What satisfies the EU's implementation may not satisfy the Singapore MAS requirements. An operator with users across both jurisdictions needs a Travel Rule solution that is configurable to each regime – and the PSP in each market will look for evidence of that configurability.

What are the most common structuring mistakes in PSP and acquiring agreements?

The most consistently costly mistake is signing without legal review of the termination and suspension provisions. Standard PSP agreements for high-risk merchants – and digital-asset businesses are almost universally classified as high-risk – include unilateral termination clauses exercisable on short notice, sometimes without stated cause. An operator who has onboarded users, funded a rolling reserve and built a product on top of a PSP relationship can find fiat rails severed within days. The reserve may then be held for an extended period post-termination as a chargeback buffer.

Second, operators routinely underestimate the importance of the "permitted activities" clause. The PSP agreement specifies, often in a schedule, the exact business activities it covers. A crypto exchange that subsequently adds a staking product, an NFT marketplace or a lending function may find that new activity falls outside the permitted-activities scope. The PSP did not consent to it. This creates a breach-of-contract exposure that the PSP can use to justify termination and reserve retention.

Third, currency and settlement mismatches are common. An operator whose revenue is denominated in crypto but whose PSP settles in EUR faces FX exposure that is not always hedged in the agreement. If the PSP's settlement cycle is weekly and the EUR/USD or EUR/GBP rate moves materially, the operator bears the loss. This is a negotiable term – but only if it is negotiated before signature.

Fourth, multi-entity structures create hidden risk. A group with an operating entity in one jurisdiction and a parent or holding entity in another may satisfy the PSP's onboarding requirements at the entity level but create a problem when the PSP's risk team re-examines the group structure annually. The group entity that was not disclosed – perhaps because counsel thought it irrelevant – can trigger a "material change" notification obligation. Failure to notify is itself a breach.

Decision matrix: which PSP and acquiring structure fits which operator profile?

Matching the operator's profile to the right instrument and the right PSP jurisdiction requires working through four variables: regulated status, user geography, product scope and banking ambition. The following profiles reflect the fact patterns we see most frequently.

Profile A – Early-stage exchange, EU user base, CASP authorisation pending. This operator should pursue onboarding with an EU EMI or payment institution licensed under the relevant national competent authority under the MiCA-adjacent framework, using a bank-transfer PSP agreement in the first instance. Card acquiring should be deferred until the CASP authorisation is in hand, because card acquirers will require it. The principal risk is onboarding delay during the CASP review period; the mitigation is a limited-scope PSP agreement that does not expose the operator to card-scheme chargeback liability before the regulatory position is clear.

Profile B – Established VASP, Asia-Pacific user base, MAS DPT licence held. This operator can approach Singapore MAS-licensed PSPs and regional acquiring banks with a strong compliance profile. The cross-border issue is the treatment of users outside the MAS perimeter – particularly in jurisdictions without a recognised VASP regime. The PSP agreement must carve those users out or the operator must obtain a separate regulated arrangement for each material market. Timeline to a workable acquiring arrangement in this profile is typically faster than the EU path, but scheme-level restrictions on crypto merchants remain.

Profile C – Token issuer, global raise, no payment licence held. This profile has the narrowest PSP options. Card acquiring for token sales is generally unavailable through mainstream acquirers. Bank-transfer PSPs will onboard only if the issuer can demonstrate its own regulatory status – typically a prospectus regime compliance or an exemption analysis. The practical path is often a licensed intermediary arrangement, where a regulated entity holds the PSP relationship and the issuer is a sub-merchant. This creates a disclosed intermediary layer that must be structured carefully to avoid unlicensed payment activity.

Profile D – Custodian, institutional client base, no retail exposure. This operator may not need an acquiring agreement at all. Its fiat flows are institutional wire transfers. The relevant instrument is a corporate banking agreement with an EMI or payment institution that has a clear digital-asset onboarding policy. The cross-border issue is the banking institution's jurisdiction: a UK FCA-regulated EMI may restrict the custodian's use of accounts for certain high-risk jurisdictions. An ADGM/FSRA-regulated institution may have different coverage. The stack decision is driven by the location of the custodian's institutional clients.

A cross-border PSP recovery in practice

In a recent matter, a crypto exchange operating across multiple jurisdictions had its PSP agreement terminated with limited notice after the PSP's compliance team flagged users in a jurisdiction that had been omitted from the permitted-geography schedule at onboarding. The operator's rolling reserve – representing several weeks of processing volume – was held post-termination. We reviewed the agreement, identified that the termination had not followed the procedural requirements in the contract's cure-and-notice clause, and engaged the PSP's legal team directly. The reserve was released within weeks of the dispute being framed as a contractual matter rather than a compliance matter. Separately, we mapped a replacement PSP structure across two licensed entities that covered the full user-geography without a geographic disclosure gap. The operator resumed fiat-rail processing before the end of the quarter.

Related at OBOLUS

FAQ

Why do banks close crypto company accounts?

Banks close crypto-company accounts primarily because the account activity conflicts with the institution's internal risk policy, its regulator's expectations, or the terms of the account agreement. Common triggers include undisclosed changes to the business model, transaction volumes that exceed profiled limits, adverse media or enforcement signals linked to counterparties, and failure to meet periodic enhanced due-diligence requests. The solution is proactive disclosure, a documented AML programme and a banking relationship with an institution that has a defined digital-asset onboarding policy rather than a de facto one.

How can a VASP onboard with an EMI?

A VASP can onboard with an EMI (electronic money institution) by demonstrating regulated status in its home jurisdiction, a functioning AML/KYC programme, Travel Rule compliance, and a clear description of the transaction types the EMI account will process. Most EU and UK EMIs now require the VASP to hold or be actively pursuing a relevant licence before they will open an account. The process involves an enhanced due-diligence questionnaire, corporate documentation and, increasingly, a face-to-face or video compliance interview with the EMI's onboarding team.

What does client-money safeguarding require?

Client-money safeguarding requires that funds belonging to clients are held separately from the firm's own funds, typically in a designated account with a credit institution or in qualifying liquid assets. Under EU and UK payment-services regimes, safeguarding is a licence condition, not a discretionary practice. For digital-asset operators, the relevant question is whether fiat held pending conversion to crypto – or vice versa – falls within the safeguarding perimeter. The answer depends on the precise payment-services permissions held and the structure of the customer agreement. In cross-border structures, each entity in the chain must satisfy the safeguarding rules of its own regulator.

OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance that sit around them. We map the licence stack across operating, custody and payment layers before you commit – so the fiat rails you build on are built on the right structure. We advise crypto exchanges, custodians, token issuers and funds across more than seventy licensing jurisdictions. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.

By Victor Olsen, Regulatory and Compliance Analyst – specialising in payment-services regulation and cross-border VASP compliance for digital-asset businesses.

This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.

Tell us the task — we'll map your options in 30 minutes.

Fixed-fee packages with defined scope and SLAs. The first call is free and under NDA. Business clients only.

Map your optionsinfo@oboluslaw.com · t.me/oboluslaw · reply < 2 hours