Anti-Money Laundering for Merchants

Anti-Money Laundering for Merchants: What Businesses Need to Know

Anti-money laundering becomes a merchant problem well before anyone files a suspicious activity report.

It appears when a payment provider asks for beneficial-owner information before approving an account. It appears when a marketplace discovers that every seller needs additional verification. It appears when a bank questions an unexpected change in transaction volume, when a new country changes the risk profile of the business, or when a payment launch stalls because the compliance model was designed after the commercial model.

For many merchants selling their own goods or services, the bank, acquirer or payment service provider carries much of the direct regulatory AML burden associated with the payment infrastructure. But that should not be simplified into “AML is the PSP's problem.”

Responsibilities depend on the jurisdiction, the merchant's industry and regulated status, the customers and counterparties involved, and—most importantly—what role the business actually performs in the payment flow.

A merchant accepting card payments for its own products can occupy a very different regulatory position from a marketplace paying sellers, a payment facilitator onboarding sub-merchants, or a platform enabling customers to transfer value between one another.

Understanding which model you operate is the starting point for anti-money laundering for merchants.

Why AML becomes a launch issue for merchants

AML controls are intended to prevent legitimate businesses and financial systems from being used to disguise or move proceeds of crime.

For a merchant, however, the immediate impact is usually operational.

AML-related requirements can affect:

•whether a bank or payment provider will onboard the business;

•what information must be collected from owners, customers, merchants or sellers;

•how quickly new countries can be activated;

•whether certain products or merchant categories require additional review;

•which transactions generate monitoring alerts;

•whether payments or payouts require investigation;

•how much manual compliance work accompanies growth; and

•whether a proposed marketplace or platform model changes the company's own regulatory responsibilities.

The Financial Action Task Force, which establishes international AML/CFT standards that jurisdictions implement through their own laws, centres its framework on a risk-based approach. Controls are intended to respond to the level and nature of money-laundering and terrorist-financing risk rather than treating every customer or transaction identically.

That principle matters commercially.

The objective is not maximum friction. It is sufficient control for the actual risk.

What is anti-money laundering?

Anti-money laundering, or AML, refers to the laws, policies, procedures and controls used to prevent, detect and respond to attempts to disguise or move proceeds of crime through legitimate financial or commercial activity.

Depending on the applicable regime, an AML framework may involve:

•customer or business due diligence;

•beneficial-ownership verification;

•risk assessment;

•transaction monitoring;

•investigation of unusual or suspicious activity;

•record-keeping;

•escalation procedures;

•reporting to authorities where legally required; and

•ongoing review of customer relationships.

These controls are related, but they are not interchangeable.

KYC or customer due diligence helps establish who a customer is and understand the relationship.

Transaction monitoring looks at what happens after transactions begin.

Suspicious activity monitoring determines whether activity warrants investigation or escalation.

Sanctions screening checks relevant people, businesses or other parties against applicable sanctions restrictions.

PEP screening identifies politically exposed persons whose roles may create higher corruption-related risk; being a PEP does not itself imply wrongdoing. FATF expressly describes PEP controls as preventive rather than an indication that every PEP is involved in criminal activity.

Ongoing monitoring recognises that a customer or seller's risk can change after onboarding.

AML is therefore not one verification check performed when an account is created. Where the relevant obligations apply, it is a lifecycle of understanding risk, monitoring activity and responding when that risk changes.

How does AML apply to merchants?

The answer depends heavily on the business model.

A merchant selling its own goods or services

A conventional ecommerce merchant typically receives payments from customers for products or services that the merchant itself sells.

Simply accepting a card, bank-transfer or wallet payment does not necessarily turn that merchant into a regulated payment institution or money transmitter.

In the United States, for example, FinCEN has distinguished merchant payment-processing activity from money transmission under specific facts and circumstances. Its guidance and rulings recognise that a processor acting on behalf of a merchant receiving payment for goods or services can occupy a different regulatory position from a business whose activity is the transmission of funds itself.

That does not mean an ordinary merchant has no financial-crime responsibilities.

Separate rules can apply because of the merchant's industry, geography, transaction type or other activity. In the UK, for example, certain high-value dealers fall directly within the Money Laundering Regulations when they make or receive qualifying high-value cash payments. Current HMRC guidance reflects a £10,000 cash threshold from June 30, 2026. Merchants paid only by card, debit card or cheque do not fall within that particular high-value-dealer registration requirement merely because of the transaction value.

The broader point is more important than the threshold:

“Merchant” is not itself a universal AML classification.

A marketplace, payment facilitator or platform

The analysis changes when a business begins facilitating payments for other parties.

A marketplace may onboard sellers and arrange payouts. A SaaS platform may embed payments for its customers. A payment facilitator may onboard sub-merchants. A platform may enable transfers between users.

Depending on the jurisdiction and payment structure, those activities can bring the business closer to regulated payment or money-transmission activity—and potentially to direct AML obligations.

For U.S. money services businesses subject to FinCEN's requirements, for example, an AML program must include appropriate policies, procedures and controls, designated compliance responsibility, employee training and independent review. FinCEN also makes clear that regulated principals cannot simply contract away their own AML responsibilities to agents.

The important transition is therefore not simply small merchant → large merchant.

It is often:

selling your own product → providing payment functionality to other parties.

[Internal link opportunity: Marketplace AML Responsibilities]

AML responsibilities: merchant vs payment provider vs financial institution

One of the most common mistakes in merchant AML is treating responsibility as all-or-nothing.

In practice, several parties can have different obligations in the same payment flow.

Party

AML role that may arise

Merchant

Supplies information during provider due diligence; manages its own legally applicable controls; may investigate customer or transaction risk relevant to its business

PSP or acquirer

Conducts due diligence on merchant customers and monitors activity under its applicable regulatory framework

Bank or regulated financial institution

Applies its own AML program, customer due diligence, monitoring and reporting obligations

Marketplace/platform

May have additional responsibilities where it onboards sellers, controls funds or performs regulated payment activity

Regulated payment partner

May assume defined regulated payment and AML functions, depending on structure and jurisdiction

This is why a merchant should ask which party performs each control, rather than simply asking whether the PSP "handles AML."

A PSP's AML program exists to satisfy the PSP's responsibilities and manage the risks of its own regulated business. It does not automatically satisfy every independent obligation another participant may have.

At the same time, merchants should not assume that controls imposed by a provider mean the merchant itself is legally required to operate an identical regulatory AML program.

The allocation needs to be determined from the actual legal and operating model.

Common AML controls merchants encounter

Even merchants without a direct institutional AML-program obligation are likely to encounter AML controls through banks, acquirers and payment providers.

Customer and business due diligence

Customer due diligence, or CDD, establishes who a customer is and helps a regulated business understand the purpose and expected nature of the relationship.

For business customers, this can extend into KYB—Know Your Business—including information about the legal entity, business activity and beneficial owners.

The FCA's 2026 review of regulated firms' CDD controls reinforces the importance of policies, CDD and enhanced due diligence, compliance monitoring and audit as elements of effective financial-crime controls.

For merchants, this often explains why a provider asks for more than incorporation documents before enabling payments.

Enhanced due diligence

Higher-risk relationships may require deeper review.

FATF guidance describes enhanced measures that can include obtaining more information about the customer, beneficial owner, intended relationship, source of funds or source of wealth and applying more intensive ongoing monitoring where risk is higher.

Enhanced due diligence should therefore not be confused with simply collecting more documents from everyone.

It is a risk response.

Sanctions screening

Sanctions screening is closely related operationally to AML, but it is a separate compliance issue.

That distinction can be especially important for standard merchants.

In the United States, OFAC states that all U.S. persons must comply with applicable U.S. sanctions—not merely regulated banks and payment companies. OFAC has also specifically stated that firms engaging in or facilitating online commerce should use compliance measures appropriate to their sanctions exposure.

A merchant should therefore not conclude that limited direct AML-program obligations mean limited sanctions exposure.

[Internal link opportunity: Sanctions Screening Explained]

PEP screening

A politically exposed person is someone entrusted with a prominent public function.

PEP screening is designed to identify relationships that may require additional corruption-related risk assessment and due diligence. It is not a sanctions list and a PEP match is not automatically a reason to reject a customer.

[Internal link opportunity: Politically Exposed Persons Screening]

Transaction monitoring

Transaction monitoring evaluates payment behaviour for indicators that warrant investigation.

Signals can include unusual changes in volume, transaction velocity inconsistent with the customer's known business, circular movement of funds or patterns that do not appear consistent with the economic purpose of the account.

The important word is context.

A sudden increase in transactions could indicate suspicious activity—or a successful product launch. Monitoring identifies behaviour requiring analysis; it does not make the final determination on its own.

[Internal link opportunity: Transaction Monitoring Explained]

Suspicious activity investigation and reporting

Where a business is subject to applicable suspicious-activity-reporting requirements, an alert may lead to investigation and potentially a report to the relevant authority.

Those requirements vary significantly.

For example, certain U.S. money services businesses, including money transmitters, are subject to FinCEN SAR requirements. That does not mean every ecommerce merchant has the same reporting obligation.

This distinction is essential: monitoring suspicious behaviour and having a statutory obligation to file a regulatory report are not automatically the same thing.

Ongoing monitoring

CDD does not necessarily end after onboarding.

Risk can change when a customer changes ownership, enters another country, launches a different product, increases volume substantially or begins displaying activity inconsistent with the original profile.

Sanctions exposure can also change because sanctions lists and restrictions change over time. OFAC's risk-based compliance framework emphasizes ongoing assessment rather than treating compliance as a static exercise.

[Internal link opportunity: Ongoing Customer Monitoring]

What can make a merchant or transaction higher risk?

Higher risk does not mean prohibited.

It generally means the business or its regulated provider needs to understand the activity more thoroughly and determine whether stronger controls are appropriate.

Relevant risk factors can include:

•the merchant's industry and products;

•countries in which customers or counterparties are located;

•cross-border transaction patterns;

•unusually complex ownership structures;

•use of intermediaries;

•expected versus actual transaction volume;

•payment methods;

•customer or seller types;

•rapid movement of funds;

•significant changes from previously understood behaviour; and

•exposure to jurisdictions with identified financial-crime weaknesses.

Geographic risk needs particular care.

FATF publishes lists of jurisdictions under increased monitoring and high-risk jurisdictions, but it explicitly cautions that increased monitoring does not mean jurisdictions should automatically be subjected to blanket enhanced due diligence or wholesale de-risking. The FATF framework remains risk based.

This is why simply blocking every customer from a "high-risk" geography is not the same as having a mature compliance program.

Examples of activity that may warrant review

The Version 1 principle remains useful: certain patterns should trigger questions, not automatic conclusions.

Examples include:

Transaction structuring. Repeated transactions apparently designed to remain below a known control or reporting threshold can be relevant to suspicious-activity analysis.

Refund behaviour inconsistent with ordinary commerce. Repeated payments followed by unusual refund behaviour—particularly where destinations or parties do not align with the original transaction—can warrant investigation.

Identity or business information that does not reconcile. Names, addresses, ownership information or documents that materially conflict may indicate that additional verification is needed.

Account velocity outside the expected profile. A merchant or seller expected to process relatively low volume that suddenly handles substantially different activity may require reassessment.

None of these signals proves money laundering.

Good monitoring finds anomalies. Good investigation determines what they mean.

How AML requirements affect international expansion

An AML process built for one country should not be assumed to work unchanged everywhere else.

FATF provides international standards, but national governments implement those standards through their own laws, regulated sectors, supervisors and reporting systems.

As a merchant expands, several things can therefore change at once:

•the legal AML perimeter;

•required customer or merchant data;

•beneficial-ownership requirements;

•higher-risk-country treatment;

•sanctions regimes;

•reporting procedures;

•acceptable identification documents;

•provider risk appetite; and

•the regulated entity serving the merchant.

A business may also change its own regulatory position without noticing.

A merchant can begin expansion as an ordinary seller and later introduce marketplace sellers, stored balances, seller payouts or peer-to-peer functionality.

Those product decisions can be more important to the AML analysis than the company's transaction volume.

[Internal link opportunity: AML Requirements by Country]

Why AML requirements can slow payment launches

AML often becomes a launch delay because important decisions are made in the wrong order.

The business chooses a market, signs commercial commitments, builds checkout functionality and sets a target launch date.

Only afterward does someone determine that:

•additional seller information is required;

•beneficial owners need verification;

•certain customers need enhanced due diligence;

•payment monitoring must be configured;

•a regulated partner requires new data fields;

•the proposed funds flow changes the platform's regulatory position; or

•the new jurisdiction requires a different compliance workflow.

At that point, compliance is no longer a review.

It is a product redesign.

The problem is not that risk controls exist. The problem is discovering their operational requirements after the system that needs to support them has already been built.

How merchants can reduce AML-related launch friction

Determine which obligations actually belong to the business

Start with the business model and payment flow.

Ask whether the company sells only its own goods or services or facilitates payments for others. Identify who receives funds, who controls them, who onboards sellers and which entities are regulated.

Do not infer the answer from the fact that a PSP is involved.

Map provider requirements before integration

Before selecting a provider or committing to launch timing, establish what information the provider will need from the merchant, owners, customers or sellers.

That can turn unexpected compliance work into ordinary product requirements.

Build a risk-based process rather than a universal friction layer

FATF's framework is explicitly risk based. Higher risk can justify stronger controls; lower risk can justify proportionate treatment.

The objective should be to apply the right control, not the most burdensome control available.

[Internal link opportunity: Payment Compliance Risk Assessments]

Separate screening, monitoring and investigation

These should not become one generic "compliance check."

A scalable system distinguishes:

Identity and business data → screening and risk assessment → decision → transaction monitoring → alert → investigation → escalation or closure → ongoing reassessment

This makes it easier to automate repetitive checks while preserving human review for ambiguous cases.

Centralize reusable compliance data

If beneficial-owner information, verification results or risk decisions are recreated for every payment provider or market, expansion becomes unnecessarily repetitive.

A structured data model makes it easier to identify what can be reused, what needs refreshing and what is jurisdiction specific.

Assign clear ownership

Version 1 was right to emphasize this point.

Compliance processes degrade when nobody owns them after launch.

Someone should be responsible for maintaining policies, reviewing changes in the business model, managing provider requirements and ensuring that risk controls evolve as products, transaction patterns and jurisdictions change.

A merchant AML readiness checklist

Before launching into another market, adding a PSP or introducing platform functionality, a merchant should be able to answer:

•Have we determined whether our business itself has direct AML obligations in each relevant jurisdiction?

•Do we understand what AML responsibilities sit with our bank, PSP or acquirer and what remains with us?

•Are we selling only our own goods or services, or are we facilitating payments for sellers, customers or other third parties?

•Do we know what customer, merchant, seller and beneficial-owner information our payment partners require?

•Have we distinguished AML obligations from sanctions requirements?

•Do we understand which customers or transactions may require enhanced review?

•Is transaction monitoring appropriate to the actual business and payment risk?

•Do we have a process for investigating—not simply generating—alerts?

•Do we understand any suspicious-activity-reporting obligations that apply directly to our business?

•Can customer or seller risk be reassessed after onboarding?

•Are compliance requirements included in market-launch planning before engineering is complete?

•Is there a clearly accountable person or team responsible for maintaining the program?

Key takeaway

Anti-money laundering for merchants is not one universal list of checks.

For a conventional merchant accepting payment for its own goods or services, much of the regulated AML infrastructure may sit with banks, acquirers and payment providers. For marketplaces, payment facilitators, fintech-enabled platforms and other businesses moving toward third-party payments, the company's own responsibilities can become materially different.

Separate sanctions requirements can also apply even where a merchant is not itself subject to a full financial-institution AML regime.

The practical goal is therefore not to build every possible compliance control.

It is to understand which risks exist, which rules apply, which party owns each responsibility and what infrastructure is required before launch.

Merchants that answer those questions while designing their payment and expansion model can build due diligence, screening, monitoring and review into normal operating infrastructure.

Those that wait until the end of the launch frequently discover that compliance is not a final approval step at all.

It is part of the payment architecture.

🙂 🙂 🙂 🙂 🙂 🙂 🙂

The biggest SEO opportunity is to make it even clearer that “merchant AML” has two different meanings: AML checks performed on a merchant by its bank/PSP, and AML obligations that may apply to the merchant itself. Current search results lean heavily toward merchant onboarding/screening products, so your article can differentiate itself by answering both interpretations and then explaining where responsibility changes.

SEO recommendations

•Add a 40–60 word direct-answer box immediately after the introduction. This is the most important change I’d make. Something like:

Do merchants need AML compliance?

Not every merchant has the same direct AML obligations. For many standard merchants selling their own goods or services, regulated banks and payment providers carry much of the payment-related AML responsibility. Direct obligations can increase depending on the merchant’s industry, jurisdiction, regulated status, and whether it facilitates payments or handles funds for third parties.

That targets the likely AI Overview/snippet question without sacrificing nuance.

•Slightly strengthen the H1. The existing title is good, but I think this is stronger for search:

Anti-Money Laundering for Merchants: AML Requirements and Responsibilities Explained

It incorporates both the primary phrase and the two concepts the user is probably trying to resolve: requirements and responsibilities.

I would use:

•URL: /anti-money-laundering-for-merchants/

•SEO title: Anti-Money Laundering for Merchants: AML Requirements Explained

•Meta description: Learn how AML applies to merchants, what banks and PSPs handle, when merchants may have direct obligations, and how AML controls affect payment launches.

•Add one short section called “What does merchant AML mean?” Put it shortly before “How does AML apply to merchants?” This resolves a genuine search-intent ambiguity:

“Merchant AML” can describe both the AML/KYB checks a bank, acquirer or PSP performs when onboarding a merchant and the AML obligations that may apply directly to the merchant’s own activities. These are related but different questions.

That would help you rank against pages focused primarily on merchant screening without turning your article into a PSP onboarding article. Current search results explicitly use “merchant AML” to describe entity, beneficial-owner, sanctions and ongoing screening at onboarding.

•Change two H2s to capture stronger secondary queries. I’d change:

•Common AML controls merchants encounter → What AML compliance requirements do merchants encounter?

•How does AML apply to merchants? → Do merchants have AML compliance obligations?

The body can stay largely unchanged.

•Preserve the AML/sanctions distinction. This may actually become one of the page's strongest authority signals. A lot of commercial content lumps sanctions, PEPs and AML into one generic screening product. Your article explicitly explains that they interact but are not legally synonymous. That is editorially stronger and semantically richer than many current results.

•Add an FAQ section, but do it for search coverage—not because I expect FAQ rich results. I’d use five questions:

•Do merchants need AML compliance?

•Is AML the merchant's responsibility or the payment provider's?

•What is merchant due diligence?

•What is the difference between AML monitoring and sanctions screening?

•Do marketplaces have different AML responsibilities from ordinary merchants?

Keep each answer around 50–90 words. These are also strong candidates for AI-generated search retrieval.

•Add one phrase around “merchant due diligence.” Your content already explains CDD/KYB, but the exact concept could be more explicit. For example:

“From the payment provider's perspective, merchant due diligence can include verifying the business, ownership, expected activity, industry, geography and source of payment volume before—and sometimes after—the account is approved.”

This captures the secondary keyword naturally without stuffing it.

Editorial recommendations

The strongest editorial section is currently “AML responsibilities: merchant vs payment provider vs financial institution.” I would elevate it even more. That is the answer most competing generic AML explainers fail to give merchants.

I’d make three additions.

First, immediately after the responsibility table, add a sentence such as:

A merchant can therefore be subject to a PSP's AML controls without necessarily being legally required to operate the same AML program as the PSP.

That is concise, memorable, and prevents a very common misunderstanding.

Second, I would add a tiny “What changes as the business evolves?” progression:

Merchant selling its own products → Marketplace onboarding sellers → Platform controlling seller payouts → Payment facilitator / regulated payment activity

The purpose is not to say every step automatically creates AML obligations. It visually reinforces the excellent Version 1 insight that responsibilities can change as the payment model changes.

Third, consider cutting a little of the jurisdictional detail from the UK high-value-dealer example. It is accurate and useful, but because this is the cluster overview, the exact £10,000 threshold may date the article faster than necessary. You could retain it as an illustrative example but make it a sidebar/callout rather than part of the central narrative. Country-specific depth ultimately belongs in AML Requirements by Country.

Visual assets I would create

I would create three, with the first two being priorities.

Visual 1 — “Who Owns AML Responsibilities?”

This is the most valuable infographic for this page.

A horizontal comparison:

Traditional merchant

Customer → Merchant → PSP / Acquirer → Bank

PSP/bank performs regulated payment-level AML; merchant handles applicable business-specific responsibilities.

Marketplace / platform

Buyer → Platform → Seller

Seller onboarding + third-party payments can change the compliance analysis.

Regulated payment model

Buyer → Licensed payment provider → Seller

Provider performs defined regulated functions; platform may still retain separate responsibilities.

Put underneath:

The key question: what role does your business actually perform in the payment flow?

That graphic directly supports the article's unique thesis.

Visual 2 — “The Merchant AML Lifecycle”

Use a clean seven-stage flow:

Business/customer data

→ CDD / KYB

→ Risk assessment

→ Sanctions & PEP screening

→ Payment activity

→ Transaction monitoring

→ Alert → investigation → escalation/closure

↺ Ongoing monitoring

Here are examples of the general visual language—not assets I would publish directly:

https://images.openai.com/static-rsc-4/MFIqWuMY9KvQ_waVlYTBEHBMdY6KuRQRcUMnspMM-7sM0JifexzYRU0S9HTuPsNKlaiAl7UaXFVwEf2DU9v2zUQyWSkqXwdo6lc6xjk7FR8U9_MQmwy9aYSquyhbdpK57MNpH-vM7DRwkDxnBJS_ydwm5x7eTGpllpRecYOB0t_-XnORHTEpf4o28rsOqSCL?purpose=fullsize

https://images.openai.com/static-rsc-4/z2leCE00HDzlEOzDg2-M9HpqxXTBg7RnBdg984DAlftZ0pnpizSgKLezWIqt_8s6LJE5GiA9iRWLtc4Bspqv0v-g1odEeuNiI07nWgjtV2P0T0iPfQqm41edYSHoNed2zMcFOJfZhzzY_ysWRN-rUTzKKx7oY7SIzcCxJ5yLAW0CUa0d-yXBrJ96VuqLZPf9?purpose=fullsize

https://images.openai.com/static-rsc-4/AJ2c_pG1-luERQflcHEmyBJLu22xj1K-UcB0t1RYswtDJlORQYzmJEJhprUvkT5IdDu9Sdwe04cqHi-XPPcUBtCGiHk79QjqENTQJJZh5iEFJ-6Pm9RNr9MdTNMzkgubWSheEs0xrRRMomI_IUVE2EEOVMp8hapVxfaOFAAVCjDJeY6mAmc8LFvZf2d1FI1J?purpose=fullsize

Visual 3 — “What Makes AML Risk Increase?”

A simple four-quadrant graphic:

Business model

Geography

Third-party payments, marketplaces, complex ownership

Higher-risk jurisdictions, cross-border activity

Transaction behavior

Customer/counterparty

Unusual volume, velocity, refunds, circular movement

Ownership complexity, inconsistent information, elevated-risk relationships

Caption:

Higher risk does not automatically mean prohibited. It usually means more information, monitoring, or review may be appropriate.

That reinforces the FATF risk-based principle rather than creating a fear-based “red flag” infographic. FATF continues to emphasize risk-based, proportionate controls rather than indiscriminate de-risking.

One additional SEO asset I strongly recommend

Create a downloadable or indexable “Merchant AML Readiness Checklist” from the checklist already in the article. It can exist both inline and as a branded one-page graphic.

Title it:

Merchant AML Readiness Checklist: 12 Questions Before Launch

That gives you something highly linkable, useful for sales enablement, reusable on LinkedIn, and suitable for Google Images while reinforcing the parent article rather than competing with it.

Overall, I would not rewrite the article extensively. The content architecture is right. The biggest gains now come from a clearer direct-answer snippet, explicitly resolving the two meanings of “merchant AML,” and adding the responsibility + lifecycle visuals. Those changes would make the article substantially stronger for both traditional search and AI retrieval.

V1

Anti-Money Laundering for Merchants

Most merchants assume anti-money laundering compliance is something their bank or payment provider handles on their behalf — and for a large share of standard merchants, that's mostly true. But the moment a business starts facilitating payments to or from third parties — a marketplace paying out sellers, a platform enabling peer-to-peer transactions, a payment facilitator model — AML obligations can shift from "your PSP's problem" to "your problem," often without the business fully realizing the shift has happened.

This is general information, not legal advice — AML obligations vary meaningfully by jurisdiction and business model, and any specific compliance program should be built with qualified legal counsel, not from a summary article.

Why This Depends Heavily on Your Business Model

A standard merchant selling its own goods or services through a PSP typically has limited direct AML obligations of its own — the acquiring bank and PSP carry the primary regulatory responsibility for monitoring the money flowing through their systems, screening the merchants they onboard, and reporting suspicious activity at that level.

A marketplace, payment facilitator, or platform enabling third-party sellers to receive funds is a materially different case. Depending on the jurisdiction and the specific payment flow, this kind of business can be treated as having its own direct AML obligations — because it's the one with visibility into, and some degree of control over, the individual sellers or users transacting on its platform, in a way the underlying PSP often isn't positioned to monitor at that level of granularity.

Knowing which category your business actually falls into — and this can shift as a business adds features like split payments, marketplace functionality, or peer-to-peer transfers — is the first and most important compliance question, because it determines whether the obligations below are your responsibility or genuinely someone else's.

The Core Obligations, Where They Apply

Customer and counterparty due diligence. If you're onboarding sellers, contractors, or other parties who will receive funds through your platform, this typically means verifying their identity and, for businesses, their beneficial ownership — not just collecting a name and a bank account number.

Transaction monitoring. Watching for patterns that suggest money laundering rather than ordinary commerce: unusual transaction volume relative to a seller's history, transactions structured to stay just under reporting thresholds, rapid movement of funds in and out of an account with no clear business rationale, or a pattern of transactions between accounts that otherwise show no legitimate connection.

Sanctions screening. Checking customers, sellers, and counterparties against relevant sanctions lists before onboarding and on an ongoing basis, not just as a one-time check at signup. Sanctions lists are updated regularly, which means a party that screened clean at onboarding needs to be re-checked periodically, not assumed permanently cleared.

Suspicious activity reporting. In many jurisdictions, businesses with AML obligations are legally required to report certain suspicious activity to a relevant authority, with specific rules about what triggers a report and how quickly it must be filed.

Record-keeping. Maintaining documentation of due diligence performed, monitoring conducted, and any reports filed, for a period defined by the relevant jurisdiction's requirements — this becomes the evidence a business relies on if its compliance program is ever examined.

Ongoing monitoring, not a one-time onboarding check. AML obligations don't end once a seller or customer is verified — a party that looked legitimate at onboarding can begin exhibiting suspicious patterns later, and a compliance program needs to account for this continuously rather than treating verification as a single completed task.

Suspicious Patterns Worth Recognizing

Structuring. Deliberately breaking a larger transaction into multiple smaller ones specifically to stay under a reporting or monitoring threshold. This is one of the more recognizable red flags precisely because the pattern itself — several transactions just under a round threshold, from the same source, in a short window — doesn't have many legitimate explanations.

Refund or chargeback patterns used to move funds rather than genuinely correct a transaction. A pattern of payments followed by refunds to a different destination, or between parties with no clear commercial relationship, can indicate an attempt to layer funds through what looks like ordinary transaction activity.

Identity information that doesn't hold together. Mismatched names, addresses, or business details across different verification steps, or documentation that appears altered or inconsistent, are basic but important signals not to wave through simply because a checkbox was technically completed.

Account velocity that doesn't match the stated business. A seller or account onboarded as a small, low-volume operation that suddenly processes volume far outside that profile warrants a fresh look, not an assumption that growth alone explains it.

What Non-Compliance Actually Costs

Beyond direct regulatory fines, which can be substantial, AML failures carry consequences that compound over time: loss of banking and payment processing relationships (a bank or acquirer that identifies a partner as an AML risk will often terminate the relationship rather than remediate it), reputational damage that affects the ability to secure new partnerships, and in some jurisdictions, personal liability for the individuals responsible for a business's compliance program, not just liability at the corporate level.

Practical Steps for Merchants

Determine definitively which obligations actually apply to your specific business model. This isn't something to infer from general knowledge of AML — it depends on your specific payment flow, jurisdiction, and whether you're facilitating payments to third parties, and it deserves a direct answer from qualified counsel rather than an assumption carried over from a different, simpler business model you may have started with.

Don't assume your PSP's AML program covers your own direct obligations. A PSP's compliance program addresses risk at the PSP's own level — it does not automatically substitute for a marketplace or platform's independent obligations if those obligations exist for your specific model.

Build monitoring proportional to your actual risk, not a generic template. A platform with high-volume peer-to-peer transfers has a different risk profile than one selling to consumers directly, and monitoring intensity should reflect that rather than applying one-size-fits-all rules regardless of business model.

Screen on an ongoing basis, not just at onboarding. Sanctions lists change; a party that cleared screening a year ago should be checked again periodically, not assumed permanently clear.

Designate clear internal ownership for compliance. A program with no specific person or team responsible for maintaining it tends to degrade over time as the business changes, even if it was built correctly at launch.

A Starting Checklist

•Have you determined, specifically, whether your business model carries independent AML obligations beyond what your PSP already covers?

•If you onboard sellers or facilitate third-party payments, do you have real due diligence in place beyond basic contact information?

•Is sanctions screening performed on an ongoing basis, not just at initial onboarding?

•Do you have transaction monitoring in place that's proportional to your actual risk profile, not a generic template?

•Do you know your jurisdiction's specific requirements for suspicious activity reporting, including what triggers a report and the required timeline?

•Is there a clearly designated person or team responsible for maintaining your compliance program on an ongoing basis?

For marketplaces and platforms with independent AML exposure, Terminal3's Merchant of Record model is built to absorb much of this compliance burden directly, while Medusa and Passport provide the underlying risk and identity signals that support ongoing monitoring rather than a one-time onboarding check. The goal is giving merchants a clearer line between what's genuinely their responsibility and what a partner built for this specific compliance burden can take on instead.