Regulatory Requirements by Market
There is no single global rulebook for accepting, moving, settling, or facilitating payments. A business can use essentially the same checkout in Paris, London, New York, Singapore, Sydney, and São Paulo while the regulatory architecture underneath that checkout changes materiall
Payment Regulatory Requirements by Market: A Framework for Global Expansion
There is no single global rulebook for accepting, moving, settling, or facilitating payments.
A business can use essentially the same checkout in Paris, London, New York, Singapore, Sydney, and São Paulo while the regulatory architecture underneath that checkout changes materially from one market to the next.
The mistake is therefore to ask only:
Can we accept payments in this country?
The better question is:
What combination of licensing, acquiring, money movement, financial-crime, foreign-exchange, consumer-protection, safeguarding, reporting, operational-presence, and payment-method requirements applies to our specific business model in this market?
That distinction becomes especially important for marketplaces, SaaS platforms, fintechs, embedded-payment products, businesses paying third parties, and merchants entering many countries at once.
A conventional merchant selling its own goods through a regulated PSP can present a very different regulatory question from a marketplace that receives buyer funds and later distributes them to independent sellers—even when both businesses describe the user experience as “accepting payments.”
The practical framework below organizes payment regulatory requirements by market around 14 questions that expansion teams can answer repeatedly for every country they enter.
The framework matters because payment compliance is not one launch checklist.
It is a market-by-market operating-model decision.
What payment regulatory requirements should a business evaluate before entering a new market?
Before launch, determine at minimum:
What payment activities will the business actually perform?
Does the company itself need a licence, registration, or authorization?
Can or should acquiring be local?
Will the company hold, control, or transmit third-party money?
Does the model involve sellers, contractors, creators, or other third parties?
Who performs foreign exchange?
Who must undergo KYC, KYB, or AML controls?
Which sanctions regimes and geographic restrictions are relevant?
Which consumer-protection requirements apply?
Must customer funds be safeguarded or otherwise protected?
Which regulatory and transaction reports are required?
Is local operational presence required?
Can an authorization from another jurisdiction be relied upon?
Do local payment methods create additional requirements?
Then consider separately whether privacy, data-transfer, tax, sector-specific, card-network, or other obligations affect the launch.
A “yes” to payment acceptance does not answer any of those questions by itself.
Why payment regulation changes by market
Most jurisdictions are trying to solve broadly recognizable problems:
Who is allowed to provide payment services?
How should customer funds be protected?
How should financial crime be detected?
What information must customers receive?
What happens when a payment is unauthorized or disputed?
Who can issue stored monetary value?
How should regulated institutions report to authorities?
Which institutions may connect to domestic payment systems?
But different legal systems draw the regulatory boundary differently.
One country may call a business a payment institution.
Another may regulate the relevant activity as money transmission.
Another may distinguish:
Merchant acquisition
Domestic money transfer
Cross-border money transfer
Account issuance
E-money issuance
under one statutory payments regime.
Two activities that look commercially similar can therefore produce different:
Licence categories
Regulators
Local-presence requirements
Capital requirements
Safeguarding obligations
AML obligations
Cross-border permissions
This is why global payment regulation should be evaluated by activity and payment flow, not by searching for the equivalent of one licence name in every country.
The 14 questions to answer before entering a country
What payment activities will the business actually perform?
Start with regulatory classification.
Do not begin with:
“We are a marketplace.”
or:
“We are a SaaS company.”
Begin with the transaction.
Ask:
Who sells the product?
Who contracts with the buyer?
Who receives the payment?
Who controls the money?
Is money being held?
Is money later transferred to another party?
Is stored value created?
Is a payment account provided?
Is the company acquiring transactions for other merchants?
Is the company initiating transfers?
Is it performing FX?
This distinction frequently determines whether the business is simply a merchant accepting payment for itself or may be providing a regulated payment service.
A merchant accepting payment for its own goods is not automatically equivalent to a business transmitting funds for third parties.
Internal link opportunity: Payment Licensing Explained
Does the company itself need authorization?
Once the activity is understood, ask:
Who needs to be regulated for this flow?
Possible answers include:
The business itself
Its PSP
Its acquirer
A bank
An e-money institution
A money transmitter
A marketplace-payment provider
A Merchant of Record
Several participants
A business may be able to structure a launch through an appropriately regulated partner rather than becoming licensed itself.
But:
using a licensed PSP does not automatically mean every activity performed by the merchant falls under the PSP's licence.
The payment flow needs to show that the regulated activity actually sits with the regulated provider.
Internal link opportunity: Does a Merchant Need a Payments Licence?
Is local acquiring required—or commercially valuable?
Regulation and commercial payment architecture overlap here.
A merchant may technically be able to process customers cross-border while still finding that local acquiring improves:
Authorization
Payment-method access
Settlement
Currency support
Customer experience
In other cases, domestic acquiring or participation in a particular payment arrangement can create local:
Entity
Banking
Registration
Acquirer
Compliance
requirements.
Do not convert the commercial concept of “local acquiring” into a universal legal requirement.
Instead ask:
Can the merchant acquire locally under its intended structure, and what must exist locally for that arrangement?
Internal link opportunity: Local Acquiring Licensing Requirements
Does the business hold or transmit third-party funds?
This is one of the most important questions for platforms.
Compare:
Traditional merchant
Customer
↓
Merchant selling its own product
with:
Platform flow
Buyer
↓
Platform
↓
Third-party seller
If the platform:
Receives money owed to sellers
Controls when sellers are paid
Maintains seller balances
Transmits funds
Issues stored value
the regulatory analysis can become materially different.
The key question is not whether the website calls the funds:
seller balance
but what the platform legally and operationally does with the money.
Does the business operate a marketplace or platform?
Marketplaces introduce another participant into the transaction.
That can create questions involving:
Seller onboarding
KYB/KYC
Third-party funds
Split payments
Seller payouts
Negative balances
Tax reporting
Consumer relationships
A regulated marketplace-payment solution can sometimes keep the platform from directly performing the regulated fund flow.
But the actual structure matters.
A software interface that tells a licensed provider where to pay sellers can present a different regulatory profile from a platform that itself receives, holds, and redistributes seller funds.
Internal link opportunity: Marketplace Payment Licensing
Who performs foreign exchange?
A global payment may involve several currencies:
Customer pays EUR
↓
Merchant records USD
↓
Seller receives GBP
Ask:
Who performs each conversion?
At what stage?
Is the merchant itself offering FX?
Does the PSP or bank perform it?
Is FX embedded in a payout service?
Foreign-exchange regulation varies widely by jurisdiction and activity.
Do not assume that because a payment provider can settle another currency, the merchant may independently offer currency conversion to its users.
Internal link opportunity: Foreign-Exchange Licensing
Who must be identified and screened?
KYC and KYB requirements depend heavily on role.
A conventional merchant does not necessarily perform the same regulated customer due diligence that its PSP performs on the merchant.
A marketplace-payment provider may need information about:
The platform
Sellers
Beneficial owners
Other relevant parties
A payment institution may have its own customer due-diligence obligations.
The operating question is therefore:
Who is the regulated provider's customer, and which parties must the payment flow identify?
Do not treat KYC as one universal form copied into every market.
The underlying AML regime, customer type, risk, payment service, and jurisdiction matter.
Which sanctions rules apply?
Sanctions are another layer that does not map cleanly to one “payments licence.”
Potentially relevant factors include:
Merchant location
Payment-provider location
Customer location
Seller location
Banks involved
Currency
Product
Counterparties
A PSP can perform sanctions screening as part of its own obligations.
That does not necessarily extinguish the underlying business's independent obligations.
Global businesses therefore need to understand both:
provider controls
and:
their own sanctions exposure.
What consumer-protection rules apply?
Payment launch reviews often focus on licensing while underestimating conduct requirements.
Depending on the jurisdiction and activity, rules can address:
Payment authorization
Unauthorized transactions
Authentication
Fees
Refunds
Complaints
Disclosures
Recurring payments
Cancellation
Error resolution
In the EU, PSD2 currently includes conduct and authentication requirements for regulated payment services, including Strong Customer Authentication in specified circumstances. The EU is simultaneously transitioning toward the PSD3/Payment Services Regulation framework: Parliament and Council reached political agreement in November 2025, and the Parliament's ECON committee approved the negotiated text in May 2026; the European Parliament's latest published legislative tracker still described formal Parliament/Council adoption as pending.
That live transition is a good example of why market-entry compliance cannot be treated as a one-time launch exercise.
Internal link opportunity: Consumer Protection Requirements
Are customer funds subject to safeguarding?
Licensing answers:
May this company provide the payment service?
Safeguarding answers another question:
How must customer or payment-service-user money be protected while the institution holds it?
Those concepts should not be conflated.
PSD2 currently requires relevant EU payment institutions to safeguard funds received for execution of payment transactions.
The UK's Payment Services Regulations also include safeguarding requirements for relevant payment institutions, and FCA guidance describes safeguarding as part of the UK payment-services and e-money regime.
Singapore's Payment Services Act separately imposes safeguarding requirements for money received from customers on Major Payment Institutions within the applicable statutory framework.
The mechanisms and scope differ.
The principle does not:
A business that controls customer money may face obligations beyond merely having permission to provide a payment service.
What regulatory reporting is required?
Operating legally can also create continuing obligations.
Depending on the market and regulated activity, these can include:
Periodic regulatory returns
Suspicious-activity reporting
Transaction reporting
Incident reporting
AML reporting
Financial reporting
Audit
Notifications of material changes
Singapore's Payment Services Act, for example, expressly provides for periodic reporting by licensees.
Australia's current AML/CTF regime includes reporting obligations for covered entities, while 2026 reforms changed parts of the AML/CTF framework and transition requirements.
Reporting therefore needs to be designed into operations before launch rather than discovered after the first regulatory filing becomes due.
Is local operational presence required?
A regulator or provider may require some combination of:
Local company
Registered office
Directors
Compliance officer
Bank account
Capital
Employees
Responsible persons
Requirements depend on the licence and jurisdiction.
Singapore's Payment Services Act, for example, contains a place-of-business or registered-office requirement for licensees as part of its statutory framework.
The UK FCA regime similarly imposes authorization and governance expectations on firms that fall within the Payment Services Regulations or Electronic Money Regulations.
This can materially affect launch sequencing because:
“Obtain licence” may actually mean incorporating, staffing, capitalizing, banking, documenting, and obtaining regulatory approval for an operating entity.
Can an authorization from another jurisdiction be relied upon?
Never assume that a licence is globally portable.
The EU/EEA is a notable example of a regional framework that allows qualifying payment institutions to exercise rights across participating Member States through PSD2 passporting procedures.
But that should not be generalized globally.
The United Kingdom maintains a separate post-Brexit regulatory regime under the Payment Services Regulations 2017 and Electronic Money Regulations rather than automatically operating under future EU payment legislation.
The United States operates differently again, with federal Bank Secrecy Act obligations for money services businesses alongside state money-transmission licensing frameworks. FinCEN states that money transmitters can qualify as MSBs regardless of transmission volume, subject to the regulatory definition and applicable exceptions, while state frameworks continue to be administered separately even as states adopt elements of the Money Transmission Modernization Act.
Cross-border permission must therefore be verified rather than presumed.
Internal link opportunity: Cross-Border Payment Regulations
Do local payment methods create additional requirements?
Entering a market is not only a question of supporting Visa and Mastercard.
Local payment systems can introduce their own:
Participation requirements
Operational standards
Settlement arrangements
Technical certification
Capital requirements
Sponsoring institutions
Consumer expectations
Brazil illustrates this clearly.
Banco Central do Brasil regulates payment schemes and payment institutions, and its official framework recognizes activities including payment-account management, payment-instrument issuance, acquiring, and cash-in/cash-out services.
Pix adds another operational layer. Depending on institution type and participation model, participants can face specific technical, operational, capital, risk-management and settlement requirements.
Supporting a country's dominant payment method therefore may require more than adding another button at checkout.
EU/EEA: a harmonized framework that is still evolving
The EU is the clearest example of regional harmonization—but even here, businesses should not reduce compliance to:
“Europe = one rule.”
The current payment-services regime remains centered on PSD2 while the replacement PSD3/PSR package progresses through the legislative process. The November 2025 political agreement was followed by approval of the negotiated text in the Parliament's ECON committee in May 2026; as of the European Parliament's June 2026 legislative update, final formal adoption was still pending.
Under the current PSD2 framework:
Payment institutions are regulated.
Relevant institutions have safeguarding obligations.
Strong Customer Authentication applies in specified circumstances.
Payment institutions can use passporting mechanisms for cross-border activity within the framework.
For expansion teams, the operational implication is twofold.
First, a qualifying authorization in one EU Member State can be significantly more useful regionally than an isolated national licence elsewhere.
Second, the regulatory framework is currently changing.
A merchant or PSP launching a multi-year European payment program should therefore design against:
the rules in force today
and:
the transition path already visible ahead.
Internal links:
Payment Institution vs Electronic Money Institution
PSP Licensing by Country
United Kingdom: familiar architecture, separate regulatory path
The UK's system remains governed principally by the Payment Services Regulations 2017 and the Electronic Money Regulations 2011, with the Financial Conduct Authority supervising relevant payment institutions and e-money institutions. The FCA's March 2026 approach document states that most PSPs falling within the regime must be authorized or registered and identifies capital, safeguarding, conduct, reporting, complaint and related obligations.
This creates an important expansion lesson.
A company operating in both:
EU/EEA
and:
United Kingdom
should no longer treat them as one licensing project.
Their payment regimes have common historical roots, but EU PSD3/PSR developments do not automatically rewrite UK law.
That can create separate workstreams around:
Authorization
Regulatory change
Safeguarding
Consumer conduct
Reporting
Local operations
For merchants simply accepting their own customer payments through regulated providers, much of the payment-institution burden may sit with those providers.
For fintechs or platforms themselves delivering regulated payment services, the direct analysis is much more substantial.
United States: federal AML plus state licensing complexity
The United States illustrates almost the opposite regulatory architecture from the EU.
There is no single national “payment institution licence” equivalent that simply replaces state money-transmission analysis.
At federal level, FinCEN regulates money services businesses under the Bank Secrecy Act. FinCEN states that, with limited exceptions, MSBs must register and that money transmission does not have the $1,000 activity threshold that applies to certain other MSB categories.
State licensing remains a separate issue.
The Conference of State Bank Supervisors continues to track state adoption of the Money Transmission Modernization Act, with multiple additional state enactments and implementations taking effect in 2025 and 2026. That reflects meaningful harmonization efforts, but not a conversion of U.S. money-transmission licensing into one federal licence.
For a business transmitting third-party funds nationally, market entry can therefore involve:
Federal BSA/MSB analysis
+
State licensing analysis
+
State-by-state requirements
For an ecommerce merchant simply selling its own products and using licensed payment providers, the analysis can be very different.
This is precisely why:
“We accept U.S. payments”
and:
“We provide payment services throughout the United States”
should never be treated as equivalent regulatory statements.
Internal link opportunity: Money Transmitter Licensing
Singapore: payment activities are explicitly classified
Singapore's Payment Services Act provides a particularly useful illustration of activity-based regulation.
The current statute includes a licensing framework for payment-service providers and recognizes payment-service categories that include activities such as:
Account issuance
Domestic money transfer
Cross-border money transfer
Merchant acquisition
E-money issuance
Digital payment-token services.
The Monetary Authority of Singapore's current public register separately identifies Standard Payment Institutions and Major Payment Institutions, including which regulated activities individual institutions are licensed to provide.
Major Payment Institutions are also subject to statutory safeguarding provisions for customer money within the applicable regime.
The commercial lesson is important:
A licence category should not be evaluated independently of the specific services the business wants to provide.
A PSP authorized for one payment activity does not necessarily have every payment activity in its regulatory scope.
When selecting a partner, verify:
institution
licence
specific permitted activity
rather than:
“This company is regulated in Singapore.”
Australia: current rules plus an active reform program
Australia deserves particular caution because payments regulation is actively evolving.
The government is developing a modernized licensing framework for payment-service providers. Treasury's March 2026 update says the proposed reforms are being progressed in two tranches; draft Tranche 1 legislation covers regulated payment-function definitions, licensing obligations, safeguarding payment-related money, exemptions, unclaimed money, prudential powers, and a revised ePayments Code framework.
That means expansion teams should distinguish:
law currently in force
from:
proposed future payments licensing architecture.
Australia also separately regulates financial-crime obligations through AUSTRAC. Updated AML/CTF obligations took effect on 31 March 2026 for relevant entities, with transitional arrangements applying to parts of implementation. AUSTRAC also requires remittance service providers to enroll and register where the applicable rules cover them.
Australia is therefore a strong example of why compliance monitoring matters.
A launch assessment performed under one payments architecture can need significant updating while a business is still scaling the same product.
Brazil: payment institutions, payment schemes, and Pix
Brazil is a useful Latin American example because domestic payment infrastructure is an important part of market-entry strategy.
Banco Central do Brasil defines a payment institution as a non-financial legal entity performing payment services within payment schemes and identifies functions including:
Payment-account management
Payment-instrument issuance
Acquiring
Cash-in and cash-out
Other regulated payment services.
Brazil's instant-payment system, Pix, has its own participation architecture. The BCB distinguishes participant types and sets requirements around technical and operational capability, capital and settlement depending on participation model.
Brazil also continues to update the payment-system framework; BCB regulatory priorities for 2025–2026 include Pix, payment schemes, Open Finance, tokenization and other payment-system topics.
For international merchants, this creates an important distinction:
Selling to Brazilian customers is not the same thing as becoming a Brazilian payment institution or direct Pix participant.
A merchant may access Brazilian payment methods through appropriately positioned providers.
A company intending to provide payment services directly faces a different regulatory project.
High-level payment regulation comparison
Market
Main regulatory architecture
Cross-border characteristic
Important launch question
EU/EEA
PSD2 currently; PSD3/PSR transition underway
Regional passporting exists for qualifying institutions
Can the intended activity sit under an existing EEA authorization and passport?
United Kingdom
Payment Services Regulations 2017 + Electronic Money Regulations
Separate UK regime
Does the business itself perform a regulated payment/e-money activity in the UK?
United States
Federal BSA/MSB regime + state money-transmission regimes
No EU-style national passport
Does the activity constitute money transmission federally and in individual states?
Singapore
Payment Services Act; Standard and Major Payment Institutions
Licence scope tied to payment-service activities
Which payment services will the company provide, and who is licensed for each?
Australia
Existing financial-services/AML framework plus major PSP-licensing reforms underway
Regime currently transitioning
Which rules apply today, and which forthcoming reforms affect the intended model?
Brazil
BCB-regulated payment schemes/institutions + domestic payment infrastructure including Pix
Local payment architecture can materially affect implementation
Does the business merely accept local methods, or will it itself participate in regulated payment activity?
This table is deliberately high-level.
It is a triage tool, not a substitute for country-specific legal analysis.
Merchant obligations and PSP obligations are not the same
One of the most useful distinctions for expansion teams is:
Which requirements apply because we are selling a product, and which apply because an entity is providing regulated payment services?
Consider a conventional ecommerce merchant.
Customer
↓
Merchant
↓
Licensed PSP / Acquirer
The PSP may carry significant obligations involving:
Payment-service authorization
AML
Safeguarding
Regulatory reporting
Payment authentication
Transaction controls
The merchant can still retain responsibilities involving:
Consumer law
Product legality
Privacy
Taxes
Refund policy
Sanctions
Recurring-sale disclosures
Sector-specific regulation
Now compare a marketplace:
Buyer
↓
Marketplace
↓
Seller
If a licensed marketplace-payment provider controls the regulated funds flow, that may reduce direct licensing exposure for the platform.
If the marketplace itself takes control of seller funds and transfers money onward, the regulatory analysis changes.
Licensing and compliance are related, but they are not synonymous.
A company may not need its own payments licence and still have extensive compliance work to complete.
Direct licensing vs using a regulated partner
The key strategic decision in many markets is not:
Comply or don't comply.
It is:
Which entity should own the regulated activity?
Direct licensing
Can provide greater:
Control
Product flexibility
Provider independence
Economics at sufficient scale
Direct access to payment infrastructure
But can require:
Regulatory application
Capital
Governance
Compliance personnel
AML systems
Safeguarding
Audit
Reporting
Local presence
Ongoing supervision
That can materially extend launch timelines.
Regulated PSP or marketplace-payment partner
Can reduce the merchant's need to recreate regulated infrastructure.
Potential benefits include:
Faster market entry
Existing licenses
Established acquiring
Existing AML/KYC systems
Existing safeguarding architecture
Local payment-method access
Trade-offs can include:
Provider dependency
Pricing
Product constraints
Underwriting
Data limitations
Less control
Merchant of Record
For some business models, a Merchant of Record can move additional responsibilities beyond payment processing.
Depending on the structure, an MoR can assume meaningful obligations involving:
Payment acceptance
Acquiring
Indirect tax
Refunds
Chargebacks
Customer transaction administration
Certain consumer-facing responsibilities
But it does not make the underlying company disappear legally.
Product legality, privacy, intellectual property, sanctions, fulfillment, and sector-specific obligations can remain with the underlying business.
Internal link opportunity: Merchant of Record Regulatory Responsibilities
Regulatory complexity should influence market-entry sequencing
Not all markets require the same amount of launch work.
A commercial expansion team may initially prioritize countries according to:
TAM
Customer demand
Revenue opportunity
Payment and compliance teams should add another dimension:
regulatory and operating effort required to make that revenue accessible.
A useful market-prioritization model is:
Market Priority=Commercial Opportunity−Regulatory/Operational Friction
Not as a literal universal financial formula, but as a decision framework.
Suppose:
Market A
High demand
Existing PSP coverage
No new merchant payment licence identified
Existing settlement currency
Familiar consumer requirements
Market B
Similar demand
New regulated activity
Local entity
New AML program
Local compliance officers
New bank account
New reporting
Specialist payout structure
The revenue opportunity may be similar.
The launch sequence should probably not be.
This is how regulatory analysis becomes a commercial expansion tool rather than an end-stage legal review.
Why compliance reviews need ongoing monitoring
The original market-entry review should not be treated as permanent.
Re-verification is particularly valuable when:
Launching a new product in an existing country
Changing the payment flow
Adding seller payouts
Introducing stored value
Adding FX
Changing PSP
Expanding transaction volume materially
Entering a regulatory transition
Adding local payment methods
The current environment supplies several real examples.
The EU is progressing from PSD2 toward PSD3/PSR.
Australia is actively developing a new PSP-licensing framework while also implementing updated AML/CTF obligations.
U.S. states continue adopting and adapting money-transmission modernization legislation.
Brazil continues to evolve Pix and broader payment-system rules.
Compliance therefore requires:
Launch assessment
↓
Implementation
↓
Monitoring
↓
Material change?
↓
Reassessment
not:
Launch assessment
↓
Done forever
Data localization and privacy should remain a separate workstream
The first version of this article correctly identified data handling as another source of market-entry friction.
It should remain in the final framework—but not be conflated with payment licensing.
Different jurisdictions can impose different:
Privacy requirements
Cross-border transfer rules
Financial-sector outsourcing requirements
Cybersecurity rules
Data-storage requirements
Those can affect:
PSP architecture
Cloud regions
Reporting
Fraud systems
Customer-data flows
A business can therefore answer:
No direct payment licence required
and still discover that its technical architecture needs material changes before launch.
That is why expansion planning should separate:
legal classification
from:
technical compliance implementation.
A practical market-entry assessment framework
For every market, build one controlled assessment containing the following.
A. Business model
Document:
Product
Customer type
Seller/merchant structure
Contracting entities
Countries involved
B. Payment flow
Draw:
Customer
↓
Merchant / Platform / MoR
↓
PSP / Acquirer
↓
Funds destination
Add any:
Sellers
Wallets
Balances
FX
Payouts
If the flow cannot be explained visually, regulatory analysis will usually be harder.
C. Regulatory classification
For every participant state:
Activity performed
Funds controlled?
Customer relationship
Settlement role
Licence/registration relied upon
Relevant exemption, if applicable
Do not rely on the provider's marketing category.
D. Licence analysis
Record:
Business licence required?
Provider licence required?
Local registration?
Partner model available?
Cross-border right?
Link each conclusion to current authority or legal analysis.
E. Financial-crime controls
Identify:
KYC
KYB
Beneficial ownership
AML
Sanctions
Transaction monitoring
Reporting
Then assign the responsible party.
F. Customer and product requirements
Review:
Authentication
Disclosures
Refunds
Complaints
Recurring payments
Consumer rights
Product-specific regulation
G. Funds protection
If funds are held:
Who holds them?
Under what regulated status?
Does safeguarding apply?
Where are funds kept?
Who reconciles them?
H. Payment infrastructure
Document:
PSP
Acquirer
Local acquiring
Payment methods
Settlement
Currency
FX
Bank accounts
Local entity dependencies
I. Reporting and operations
Define:
Regulatory reporting
Transaction reporting
Reconciliation
Record retention
Audit
Incident reporting
Ongoing monitoring
J. Change monitoring
For each regulatory conclusion record:
Jurisdiction
Rule/framework
Source
Owner
Last verified
Next review
Known upcoming change
That final field is especially important.
A market-entry framework should not merely prove that launch was compliant on Day 1.
It should create ownership for Day 500.
Market-entry readiness scorecard
A simple executive-level view can then look like this:
Area
Status
Launch blocker?
Owner
Regulatory classification
Green / Amber / Red
Yes/No
Legal
Licensing
Compliance
PSP/acquiring
Payments
Third-party funds
Legal/Payments
Marketplace model
Legal/Product
FX
Treasury/Legal
AML/KYC/KYB
Compliance
Sanctions
Compliance
Consumer protection
Legal/Product
Safeguarding
Finance/Compliance
Reporting
Compliance/Data
Local presence
Legal/Corporate
Cross-border permission
Legal
Payment methods
Payments
Privacy/data
Privacy/Security
Tax
Tax
Implementation/testing
Engineering
The point is not to reduce law to traffic lights.
It is to expose what is preventing launch and who must resolve it.
A starting checklist for every new market
Before approving a payment launch, confirm:
The actual payment flow has been documented.
The regulated activities have been identified.
The business knows whether it itself needs authorization.
Every regulated partner's relevant licence and activity scope has been verified.
Any third-party funds have been identified.
Marketplace/seller payout implications have been reviewed.
Local acquiring requirements or advantages have been assessed.
FX ownership is clear.
KYC/KYB and beneficial-ownership requirements have been allocated.
Sanctions responsibilities have been allocated.
Consumer-payment and recurring-payment requirements have been reviewed.
Safeguarding requirements have been evaluated.
Regulatory reporting obligations are known.
Local entity, director, compliance, banking, or office requirements are known.
Cross-border permissions have been confirmed rather than assumed.
Local payment-method requirements have been assessed.
Privacy and data-transfer requirements have been reviewed separately.
Tax responsibilities have been assigned.
Regulatory conclusions have an owner and a last-verified date.
Known regulatory changes are being monitored.
Key takeaways
There is no universal checklist that can answer whether a global business is ready to accept payments in another country.
The same commercial product can produce a different regulatory result depending on:
Who sells
Who receives money
Who controls funds
Who pays third parties
Who performs FX
Which payment service is being provided
Which regulated institution sits in the flow
Where each participant is located
That is why the first question should not be:
Can our PSP process transactions there?
It should be:
What exactly are we doing there, and which entity is legally and operationally responsible for each part of the money flow?
For a conventional merchant, the direct payments-licensing burden may be relatively limited because regulated PSPs and acquirers perform the regulated payment activity.
For a marketplace, wallet, embedded-payments platform, money-transfer service, or stored-value product, the analysis can be much more substantial.
The operating model then becomes a strategic choice.
A business can:
build regulated infrastructure itself,
partner with licensed institutions,
restructure the payment flow,
or, where suitable:
use a Merchant of Record or marketplace-payment structure that reallocates specific responsibilities.
None eliminates the need to understand the law.
But the right structure can materially reduce the number of licences, entities, banking relationships, safeguarding arrangements, compliance processes, and country-specific integrations the company must establish directly before revenue can begin.
That is the practical purpose of evaluating payment regulatory requirements by market:
not to create the longest possible compliance checklist, but to identify the regulatory facts that genuinely determine how the business can enter the market—and design the payment operating model before those facts become launch blockers.
This article provides general information and does not constitute legal, regulatory, financial, tax, accounting, sanctions, privacy, security, or compliance advice. Payment licensing, AML/KYC requirements, safeguarding, consumer rules, cross-border permissions, reporting, operational-presence requirements, payment-method rules, and other obligations vary by jurisdiction, business model, transaction flow, product, provider, and regulatory status. Businesses should confirm the current position with qualified local counsel, regulatory specialists, relevant payment providers, and applicable regulators before launching or materially changing a payment service.
🙂 🙂 🙂 🙂 🙂 🙂 🙂
SEO, EDITORIAL & PRODUCTION RECOMMENDATIONS
Recommended SEO title
Payment Regulatory Requirements by Market: Global Expansion Guide
Alternative:
Payment Regulations by Country: A Market-Entry Framework
The first is the stronger fit with the brief's primary keyword; the second may capture more natural long-tail searches.
H1
Payment Regulatory Requirements by Market: A Framework for Global Expansion
Meta title
Payment Regulatory Requirements by Market | Global Guide
Meta description
Compare payment regulatory requirements across the EU, UK, US, Singapore, Australia and Brazil, including licensing, acquiring, AML/KYC, safeguarding, FX, consumer rules and cross-border permissions.
URL slug
/payment-regulatory-requirements-by-market/
payment regulatory requirements by market
Secondary keyword targets
Prioritize naturally:
payment regulations by country
payments compliance by country
international payment requirements
global payments regulation
market entry payment compliance
payment licensing by country
international payment compliance
global payment regulations
cross-border payment requirements
payment compliance requirements
payment regulation for global expansion
Featured-snippet opportunity
What payment regulatory requirements should a business evaluate before entering a new market?
Businesses should evaluate their payment activity classification, licensing, local acquiring, control of third-party funds, marketplace flows, foreign exchange, AML/KYC/KYB, sanctions, consumer protection, safeguarding, regulatory reporting, local-presence requirements, cross-border permissions, and payment-method-specific rules. The result depends on the business model and jurisdiction, not simply on whether a PSP can process transactions in the country.
Recommended editorial differentiation
This article should be the cluster capstone, not another licensing definition page.
Its unique job is to answer:
How do I run the regulatory workstream for a new payments market?
The deeper articles then resolve individual branches:
Is the activity regulated?
→ Payment Licensing Explained
Does our own company require authorization?
→ Does a Merchant Need a Payments Licence?
Which licence does the PSP need?
→ PSP Licensing by Country
PI or EMI?
→ Payment Institution vs Electronic Money Institution
U.S. money transmission?
→ Money Transmitter Licensing
Marketplace handling seller money?
→ Marketplace Payment Licensing
Using an MoR instead?
→ Merchant of Record Regulatory Responsibilities
Local acquiring?
→ Local Acquiring Licensing Requirements
Currency conversion?
→ Foreign-Exchange Licensing
Operating internationally?
→ Cross-Border Payment Regulations
Customer-facing requirements?
→ Consumer Protection Requirements
This creates a clean hub-and-spoke SEO architecture.
Recommended internal-link placements
Section
Suggested anchor
Destination
Regulatory classification
how payment licensing depends on the activity performed
Payment Licensing Explained
Licensing
whether a merchant needs its own payment licence
Does a Merchant Need a Payments Licence?
EU
payment institution versus electronic money institution
Payment Institution vs Electronic Money Institution
United States
how U.S. money transmitter licensing works
Money Transmitter Licensing
Marketplace
when marketplace fund flows can create licensing issues
Marketplace Payment Licensing
Local acquiring
regulatory requirements for local acquiring
Local Acquiring Licensing Requirements
FX
when providing foreign exchange can create separate regulatory obligations
Foreign-Exchange Licensing
Cross-border
how payment permissions change across borders
Cross-Border Payment Regulations
Consumer protection
consumer-protection requirements for payments
Consumer Protection Requirements
Build vs partner
which responsibilities a Merchant of Record can assume
Merchant of Record Regulatory Responsibilities
Recommended primary visual
The 14-Question Payment Market-Entry Framework
NEW PAYMENT MARKET
|
v
REGULATORY ACTIVITY
|
v
LICENSING
|
┌──────────┴──────────┐
v v
DIRECT LICENCE REGULATED PARTNER
| |
└──────────┬──────────┘
v
LOCAL ACQUIRING
|
MONEY MOVEMENT
|
MARKETPLACE FLOW
|
FX
|
AML/KYC/KYB
|
SANCTIONS
|
CONSUMER RULES
|
SAFEGUARDING
|
REPORTING
|
LOCAL PRESENCE
|
CROSS-BORDER RIGHTS
|
LOCAL METHODS
|
v
LAUNCH MODEL
Caption: A country's payment coverage is only one input. The actual launch model depends on how the business performs, outsources, or restructures the regulated activities around the payment.
Alt text: Fourteen-question payment regulatory market-entry framework covering licensing, acquiring, money movement, marketplaces, foreign exchange, AML and KYC, sanctions, consumer protection, safeguarding, reporting, local presence, cross-border permissions and local payment methods.
Recommended second visual
Same Product, Different Regulatory Architecture
Use six columns:
EU/EEA | UK | US | Singapore | Australia | Brazil
Rows:
Regulatory model
Main regulator
Cross-border licensing structure
Safeguarding
AML model
Local payment infrastructure
Current transition/watch item
The visual should deliberately not claim to be a country compliance checklist.
Caption:
The questions recur globally; the regulatory answer changes by market.
Recommended third visual
Merchant vs Platform Regulatory Flow
TRADITIONAL MERCHANT
Customer
↓
Merchant's own sale
↓
Regulated PSP/acquirer
Question:
What obligations belong to merchant
vs payment provider?
MARKETPLACE / PLATFORM
Buyer
↓
Platform
↓
Seller
Questions:
Who controls money?
Who pays seller?
Who is regulated?
This helps readers understand why company labels matter less than fund flow.
Recommended fourth visual
Direct Licence vs Regulated Partner
Direct licensing
Regulated partner
Greater infrastructure control
Faster access where partner coverage exists
Direct regulatory relationship
Provider owns defined regulated activity
Capital/governance requirements
Underwriting/provider dependency
Compliance systems
Commercial fees
Safeguarding/reporting
Less architecture control
Longer setup potential
Still requires merchant compliance analysis
Footer:
The question is not which model avoids compliance. It is which entity should own the regulated activity.
Original practical asset
Global Payment Market-Entry Assessment
A downloadable worksheet would be particularly strong for this article.
Suggested fields:
Field
Assessment
Market
Product
Customer type
Merchant entity
Payment flow
Third-party funds?
Regulated activity
Licence required?
Licence holder
Legal basis / advice
PSP
Acquirer
Local acquiring
Seller payouts
FX provider
AML/KYC owner
Sanctions owner
Consumer obligations
Safeguarding
Reporting
Local entity
Directors/officers
Local bank account
Cross-border right
Local payment methods
Privacy/data requirements
Tax requirements
Known regulatory changes
Last verified
Next review
Launch blocker
Owner
This has strong information gain because it gives Legal, Compliance, Payments, Finance, and Expansion teams one shared launch object.
Current regulatory watch items for editorial maintenance
Because this is a capstone article, I strongly recommend adding a visible:
Last regulatory review: August 2026
and maintaining an editorial watch list.
EU/EEA
Watch formal adoption, publication, entry into force, transition and application of PSD3/PSR. The latest official Parliament material retrieved for this review says political agreement was reached in November 2025 and ECON approved the negotiated text in May 2026, with formal adoption still required.
Australia
Watch enactment and implementation of the new PSP-licensing framework. Treasury still describes the framework as being implemented through reform tranches, with draft legislation under consultation/development.
Also monitor the 2026 AML/CTF transition.
United States
Track state adoption and modification of the Money Transmission Modernization Act rather than describing U.S. state licensing as static.
Brazil
Monitor Pix participation rules and wider BCB payment-system regulatory changes.
Claims from Version 1 that should be preserved—but upgraded
The first draft had several strategically strong ideas worth retaining.
“There is no single global rulebook for accepting payments.”
Keep. It remains the best conceptual entry point.
“Treat this as a per-market question, not a global one.”
Keep and elevate. This should be one of the article's recurring principles.
“Build in periodic re-verification.”
Keep. The EU, Australia, U.S., and Brazil examples now provide strong current evidence for it.
“Separate the legal questions from the infrastructure questions.”
A legal conclusion such as:
No merchant payment licence identified
does not answer whether the merchant's technology can support:
Authentication
Local payment methods
Data requirements
Reporting
Settlement
Local acquiring
“Consider where a Merchant of Record shifts the burden.”
Keep, but qualify.
The first draft went too far by suggesting an MoR moves “much” of the overall compliance burden generically. The better formulation is:
A Merchant of Record can reallocate significant payment, indirect-tax, transaction and customer-facing responsibilities for covered sales, but responsibilities involving the underlying product, privacy, sanctions, intellectual property, fulfillment and sector-specific regulation may remain with the underlying business.
That directly supports the dedicated MoR article without cannibalizing it.
Specifically verify:
Entity and brand structure
Is Terminal3 the Merchant of Record?
Which legal entities contract with merchants and consumers?
In which markets?
Market coverage
The claim:
190+ markets
requires a current approved first-party source and precise definition.
Does it mean:
Payment acceptance?
Merchant coverage?
MoR availability?
Payout availability?
All products?
Do not use the number interchangeably.
MoR responsibilities
Indirect tax calculation?
Collection?
Filing/remittance?
Consumer contract?
Refunds?
Chargebacks?
Acquiring?
Fraud?
Customer support?
Regulatory monitoring?
Regulatory monitoring
Do not publish:
Terminal3 monitors compliance across 190+ markets
unless there is substantiated operational evidence supporting that exact scope.
PSD3/PSR
Do not claim the MoR “handles the PSD2-to-PSD3 transition for merchants” generically.
The relevance depends on:
Entity
Regulated payment activity
Payment providers
Merchant role
Applicable transition provisions
A safer positioning, if verified, is:
A Merchant of Record model can reduce the number of market-specific payment and transaction-compliance relationships an underlying business manages directly, while the business remains responsible for obligations outside the MoR's contractual and legal scope.
Amber-flag claims
Require direct authoritative verification before publishing statements such as:
Every country has KYC requirements for merchants.
A merchant needs a payment licence once it exceeds a universal transaction threshold.
Every U.S. state requires the same money-transmitter licence.
FinCEN registration replaces state licensing.
An EU PI licence permits every payment activity everywhere in Europe automatically.
PSD3/PSR is already fully applicable.
The UK still follows EU payment regulation automatically.
Singapore Major Payment Institution status covers every payment service.
Australia's proposed PSP regime is already fully in force.
Pix participation is available under identical conditions to every business.
Local acquiring requires a local entity in every market.
Every payment licence includes FX.
Using a PSP removes AML or sanctions obligations from the merchant.
A Merchant of Record removes all tax or regulatory responsibility.
Data must be stored locally across “Asia and the Middle East” as a general rule.
A market's compliance requirements can be considered finished after launch.
Cluster sameness audit
Article: Regulatory Requirements by Market
Role in cluster: Capstone / market-entry hub.
Opening device: One checkout can sit on top of materially different regulatory architectures across markets.
Primary merchant problem: Expansion teams reduce regulatory readiness to whether a PSP technically processes a country.
Primary question: Which regulatory requirements must be assessed before launching payments in a specific market?
Primary format: 14-question Payment Market-Entry Framework.
Geographic evidence: EU/EEA, UK, U.S., Singapore, Australia, Brazil.
Core distinction: Payment availability vs regulatory permission and operating readiness.
Secondary distinctions: Merchant vs PSP; processing vs controlling money; licensing vs compliance; direct licensing vs regulated partner; domestic vs cross-border authorization.
Unique framework: Activity → licence → acquiring → money flow → platform → FX → AML/KYC → sanctions → consumer → safeguarding → reporting → presence → cross-border → local methods.
Main operational risk: Regulatory dependencies are discovered after engineering and commercial launch work has already begun.
Main strategic decision: Which regulated responsibilities should the business own directly and which should sit with appropriately authorized partners?
Connection to Compliance Slows Launches: Regulatory work becomes a late launch blocker when classification, licensing, entities, partners, safeguarding, reporting and local operating requirements are discovered sequentially rather than assessed upfront.
Primary SEO differentiator: Comparative framework rather than a shallow country list.
Conclusion: Global expansion should use one repeatable regulatory-question framework while producing a different jurisdiction-specific answer for every market.
Primary internal-link path: Payment Licensing Explained → Does a Merchant Need a Payments Licence? → country/licence-specific articles → MoR/marketplace/cross-border alternatives.
Boundary: The page should not become an encyclopedia of every country's payment regulation. It owns the framework businesses use to know what must be investigated before entering each market.
v1
Regulatory Requirements by Market
There is no single global rulebook for accepting payments. Every market a merchant enters brings its own combination of licensing thresholds, KYC/AML obligations, authentication requirements, data-handling rules, and consumer protections — and treating "compliance" as one checklist that applies everywhere is one of the more common and costly assumptions merchants make when expanding internationally.
This piece is a framework for thinking through what actually varies by market, plus a snapshot of a few major regulatory regimes as illustrative examples. It is not legal advice, the specifics below reflect the general landscape at the time of writing and are genuinely subject to change, and any market-entry decision should be confirmed with qualified local counsel rather than based on a summary like this one.
The Categories That Recur in Every Market
Regardless of jurisdiction, payment regulation tends to cluster around the same set of questions — what differs is the specific answer in each market, not the category of question itself.
Licensing. Does accepting or moving money on behalf of others in this market require a specific license (a payment institution license, an e-money license, a money transmitter license), and at what threshold of activity does that requirement kick in?
KYC/AML and beneficial ownership verification. What identity and business verification is required before onboarding a merchant or facilitating a transaction, and how deep does beneficial ownership disclosure need to go?
Customer authentication. Is there a Strong Customer Authentication requirement or local equivalent, and what exemptions (low-value, trusted merchant, transaction risk analysis) are available?
Data residency and localization. Does customer or transaction data need to be stored within the country's borders, or subject to specific cross-border transfer restrictions?
Consumer protection and dispute rights. What refund, cancellation, and dispute-resolution rights does local law grant consumers, independent of what a merchant's own policy says?
Tax collection. Is the merchant (or the marketplace/platform facilitating the sale) responsible for collecting and remitting VAT, GST, or a digital services tax on the transaction?
Every market answers these six questions differently, and the answers change over time as regulation evolves — which is why this needs to be treated as an ongoing monitoring exercise, not a one-time check performed at launch.
Illustrative Snapshots (Not a Complete Picture)
These are examples to illustrate how differently the same six categories can play out — not an exhaustive or current-as-of-your-reading-date legal summary. Treat every figure and status below as a starting point for verification, not a final answer.
European Union. The EU's payments framework has historically run on the Payment Services Directive (PSD2), which introduced Strong Customer Authentication and open banking requirements applied across member states through national implementation — meaning some variation exists between countries even under a shared directive. At the time of writing, the EU is in the process of finalizing a significant overhaul: a third Payment Services Directive (PSD3) alongside a new, directly applicable Payment Services Regulation (PSR), which is intended to reduce that national-level variation by making conduct rules directly binding across the EU rather than requiring separate transposition into each country's law. This is a live, moving target — merchants operating in the EU should track this transition specifically rather than assuming PSD2's rules remain static.
United States. There is no single federal payments license. Money transmission is regulated state by state, with most states requiring a Money Transmitter License in addition to federal registration as a Money Services Business with FinCEN. Requirements, fees, and timelines vary considerably by state — some states have adopted a more harmonized model licensing framework in recent years, while others maintain distinct requirements, meaning a business operating nationally may be navigating dozens of separate regulatory relationships rather than one.
United Kingdom. Following its departure from the EU, the UK maintains its own payments regulatory framework under the Financial Conduct Authority, historically closely modeled on PSD2 but now diverging on its own timeline rather than automatically following the EU's PSD3/PSR transition — a distinction worth tracking specifically for merchants operating in both the EU and UK, since the two frameworks are no longer guaranteed to move in lockstep.
Markets with data localization requirements. A number of markets, particularly across parts of Asia and the Middle East, impose requirements that certain categories of financial or payment data be stored within the country's borders, or restrict cross-border transfer without specific safeguards. This has direct implications for how a merchant's payment infrastructure and reporting need to be architected in those markets, not just a legal formality to note.
Markets with marketplace facilitator tax rules. A growing number of jurisdictions have shifted VAT/GST/sales tax collection responsibility onto the platform facilitating a transaction rather than the individual seller — a trend that has been expanding rather than staying static, and one that directly affects marketplace liability as covered elsewhere in this pillar.
Why This Requires Ongoing Monitoring, Not a One-Time Check
Regulatory frameworks that were stable for years can enter multi-year transition periods (as the EU's shift from PSD2 to PSD3/PSR illustrates), and a merchant that verified compliance at launch can find the underlying rules meaningfully different eighteen months later without necessarily noticing until an issue surfaces. This is particularly relevant for:
New product launches in an existing market, which can trigger a fresh compliance review even in a market you already operate in
Geographic expansion, which restarts the full regulatory question set in a new jurisdiction from scratch
Rapid growth in transaction volume, which can shift which licensing thresholds or reporting obligations actually apply to your business
Regulatory transitions already underway in a market you operate in, which require active tracking rather than a "we checked once" assumption
A Practical Approach for Merchants
Treat this as a per-market question, not a global one. A compliance review for one country tells you very little about another, even within the same region — the six categories above need to be answered separately for each market you operate in.
Build in periodic re-verification, not just launch-day due diligence. Given how much these frameworks shift over multi-year periods, a market you verified compliance for two years ago deserves a fresh look, not an assumption that nothing has changed.
Separate the questions your legal counsel needs to answer from the ones your payment infrastructure needs to solve. Licensing thresholds and consumer protection law are legal questions. Whether your payment stack can actually support local data residency requirements or SCA exemption logic is an infrastructure question. Both matter, and they need different experts.
Consider where a Merchant of Record model shifts this burden. For many of the questions above — particularly tax collection and consumer-facing legal responsibility — routing sales through a Merchant of Record moves much of this compliance burden to a partner built specifically to track and manage it across many jurisdictions, rather than requiring a merchant to build that monitoring capability internally for every market it enters.
A Starting Checklist Per Market
Do you know whether a specific payment license applies to your business model in this market, and at what activity threshold?
Have you confirmed current KYC/AML and beneficial ownership requirements for onboarding in this market?
Do you know whether a Strong Customer Authentication requirement or local equivalent applies, and what exemptions exist?
Have you confirmed whether data residency or cross-border transfer restrictions apply to customer or transaction data in this market?
Do you know your (or your marketplace's) tax collection and remittance obligations in this market specifically?
Is there an ongoing regulatory transition in this market you should be actively tracking, rather than assuming the current rules are static?
Has it been more than 12 months since you last verified compliance requirements in a market you already operate in?
Internal note (amber-flag, not for publication): The EU PSD3/PSR and US state-licensing details above reflect research current as of this draft. Given how actively both are moving, confirm current status before publishing, and consider adding a "last verified" date to this page so editorial knows when it needs a refresh.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗