AML + Sanctions for Stablecoin Payroll: A Practical Screening Checklist

TL;DR

• Sanctions and AML program obligations sit primarily with stablecoin issuers and the platforms processing transfers. Employer-side payroll teams typically don’t run bank-grade AML programs, but they should maintain their own per-cycle sanctions and destination controls (and not rely solely on provider screening) before each batch executes.
• OFAC administers the Specially Designated Nationals and Blocked Persons (SDN) list. U.S. persons and entities are prohibited from transacting with anyone on the SDN list, regardless of payment method. This prohibition applies to stablecoin payroll.
• The Bank Secrecy Act (BSA), administered by FinCEN, requires financial institutions to implement AML programs covering customer identification, due diligence, transaction monitoring, and suspicious activity reporting. The GENIUS Act extends these obligations to Permitted Payment Stablecoin Issuers (PPSIs).
• Screening should happen before each cycle executes, not just at worker onboarding. OFAC’s SDN list is updated continuously. A worker or wallet address that was clean last cycle may not be clean this cycle.
• Wallet address screening is as important as identity screening. OFAC publishes designated digital currency addresses within SDN entries; sending stablecoin payroll to a designated address is prohibited even if a name-based check was run separately.
• Documentation of screening outcomes, including the list/version used and the date/time of the check, belongs in the per-cycle compliance evidence package.

Disclaimer: This guide is for general informational and educational purposes only. It does not constitute legal, tax, financial, or compliance advice. AML and sanctions requirements vary by jurisdiction and evolve over time. Always confirm current requirements with qualified legal counsel and compliance experts for your specific program structure, jurisdictions, and worker populations.

Direct answer

AML and sanctions screening for stablecoin payroll requires two parallel checks before every pay cycle: identity screening of in-scope workers against applicable sanctions lists (including OFAC’s SDN list for U.S.-connected programs), and wallet address screening of destination addresses against the same lists. The primary compliance obligations sit with stablecoin issuers and the platforms processing transfers (which, under the GENIUS Act, are classified as financial institutions subject to bank-level AML and sanctions requirements). For most employer-side programs, the practical per-cycle control is sanctions screening (people + wallets) and documentation; full BSA AML program requirements sit with regulated issuers and transfer platforms. Employer-side programs should layer their own screening on top of provider controls, retain per-cycle documentation, and have a defined process for handling flags before the payout batch executes.

The regulatory framework: who carries what obligation

Understanding AML and sanctions in stablecoin payroll starts with clarity on who carries which obligation, because the structure is layered.

At the issuer and platform level

The GENIUS Act, signed into law on July 18, 2025, classifies Permitted Payment Stablecoin Issuers (PPSIs) as financial institutions under the Bank Secrecy Act. That means issuer/platform layer obligations include bank-grade AML expectations: customer identification programs, customer due diligence, transaction monitoring, suspicious activity reporting to FinCEN, and effective sanctions compliance programs (including OFAC screening). The joint FinCEN and OFAC notice of proposed rulemaking issued on April 8, 2026 implements these requirements in detail, including screening expectations and the technical capability to block or freeze prohibited transactions, plus periodic certification expectations.

At the employer level

Employer obligations are different - but not absent. U.S. persons and entities are broadly prohibited by OFAC from transacting with SDNs and from engaging in prohibited dealings under applicable sanctions programs, regardless of the payment rail used. An employer should not rely solely on provider-side screening as the only control, especially when the employer is directing payments as part of a repeatable payroll process.

Practical consequence: a defensible stablecoin payroll program uses two layers of sanctions controls:

1) the provider’s controls, and

2) the employer’s per-cycle payroll controls (identity + destination wallet screening + documentation + exception handling).

The employer-side layer does not need to replicate a bank AML program. It should cover the payroll exposure points: worker identity screening and destination wallet screening before each cycle executes, plus a documented process for handling any flags.

Issuer-layer and employer-layer obligations are distinct — but both must be active.

The practical screening checklist

Check 1: Screen all in-scope workers against current sanctions lists before each cycle

What to screen: The full legal name of each worker scheduled to receive a stablecoin payout in the current cycle, plus known aliases and common variations. For EOR programs with workers in multiple countries, account for transliteration/alternate spellings where relevant.

Which lists to screen against:

U.S.-connected programs: at minimum, OFAC SDN list

EU programs: EU consolidated sanctions list

UK programs: UK HMT Consolidated List of Financial Sanctions Targets

Add additional national lists depending on where the program operates and who is in-scope.

Timing: Before each cycle executes, against the current version of each list. Prior-cycle results are not sufficient.

Documentation (minimum):

Store a per-cycle log entry that includes:

• list(s) screened,
• list/version/date pulled,
• timestamp of check,
• outcome (no match / potential match),
• and who performed/approved the check.

Check 2: Screen all destination wallet addresses against OFAC-designated digital currency addresses

What to screen: Every wallet address scheduled to receive a stablecoin payout in the current cycle - both new addresses and previously used addresses.

Why this matters separately from identity screening: OFAC publishes designated digital currency addresses within SDN entries (often tagged by asset/network). A destination address can become designated even when a name-based screen does not surface a clear match.

Timing: Before each cycle executes, against the current SDN data.

Documentation (minimum):

Per-cycle wallet screening log that includes:

• wallet address,
• chain/network context if relevant,
• list/version/date pulled,
• timestamp of check,
• outcome,
• and any address changes since the last cycle (with approval record).

Check 3: Verify no worker is located in a comprehensively sanctioned jurisdiction (as applicable)

What to check: Some sanctions programs restrict dealings involving certain jurisdictions (and/or specific regions, sectors, or parties). A “clean” name screen does not automatically clear a jurisdiction-based exposure.

How to verify (payroll-friendly):

• Confirm each in-scope worker’s country of residence/location aligns to the program’s eligibility record (and EOR jurisdiction coverage where applicable).
• Escalate any edge cases (new markets, relocations, unusual residency facts) to legal/compliance before running the cycle.

Documentation (minimum):

A per-cycle eligibility/jurisdiction confirmation record, plus an exception note for any worker that required review.

Check 4: Confirm provider screening ran (and retain confirmation records)

What to confirm: Your stablecoin payroll provider (or the VASP/CASP processing transfers) should run sanctions controls for the current batch. Confirm screening is active pre-run and obtain confirmation post-run.

Why this matters: Provider controls don’t replace employer controls, but they strengthen defensibility. In audits and reviews, evidence of layered controls is stronger than a single check.

Documentation (minimum):

• provider batch confirmation (date/time, batch identifier, scope),
• screening outcome (incl. flags and resolution summary if any).

Check 5: Maintain a defined process for handling screening flags before the cycle closes

What the process should cover:

• what counts as a “flag” (name match, wallet match, jurisdiction concern),
• who owns first review,
• escalation path to legal/compliance,
• true positive vs false positive disposition steps,
• and required documentation before releasing/holding a payout.

Why it must be defined in advance: Flags found during cycle-close are where informal decisions and missing documentation happen.

Documentation (minimum):

• per-cycle exception log entry for each flag,
• disposition notes + basis,
• action taken (hold/block/escalate),
• and approval record.

All five checks must complete before the payout batch executes.

Per-cycle artifacts to store (minimum viable evidence package)

Store these alongside your payroll register and payout proof:

1) Worker sanctions screening log (lists + version/date + timestamp + outcome)

2) Wallet screening log (address + list/version/date + timestamp + outcome)

3) Eligibility/jurisdiction confirmation record (or exception note)

4) Provider screening confirmation record (batch + timestamp + outcome)

5) Exception/flag log + disposition notes (if any)

What a compliant stablecoin payroll program looks like (AML + sanctions)

A defensible program has five elements live before the first cycle runs:

1) Defined screening scope covering both identities and destination wallets before every cycle

2) Documented list set (OFAC + any required EU/UK/other lists based on footprint)

3) Per-cycle logs that capture list version/date, timestamps, and outcomes

4) Defined flag resolution process (owner, escalation path, required documentation)

5) Provider confirmation records retained alongside employer-side logs

Programs that have some but not all of these elements often discover the gap at the worst time: during cycle-close pressure, a regulatory inquiry, or an audit.

These five records should be retained alongside the payroll register after every cycle.

FAQs

Does OFAC sanctions screening apply to all employers running stablecoin payroll, or only to financial institutions?

OFAC prohibitions apply broadly to U.S. persons and entities, not only to financial institutions. The GENIUS Act adds additional program requirements for stablecoin issuers/platforms, but employer-side programs should still ensure they are not causing prohibited transactions.

How often is the OFAC SDN list updated?

OFAC updates the SDN list continuously, often multiple times per month (and sometimes multiple times per week). This is why per-cycle screening is required rather than an onboarding-only step.

Does screening a worker’s name against the SDN list also cover their wallet address?

No. Wallet address screening and identity screening are separate checks. OFAC publishes designated digital currency addresses within SDN entries, and an address can be designated in a way that won’t reliably surface in a name-only screen.

What should we do if a screening check returns a match for a current worker?

Do not proceed with the payout for the flagged worker until the match is reviewed and dispositioned. Many name matches are false positives; true positives require immediate escalation to legal/compliance. Document the review, the basis for the decision, and the action taken.

Is sanctions screening the same as AML screening?

They’re related but distinct. Sanctions screening checks whether a person/address is prohibited. AML covers broader risk controls (transaction monitoring, suspicious activity, due diligence). For most employer-side stablecoin payroll programs, the immediate per-cycle requirement is sanctions screening plus documentation; broader AML program requirements sit with regulated issuers and transfer platforms.

Build both layers before the first cycle runs

AML and sanctions compliance for stablecoin payroll is not conceptually complex, but it requires two things many programs underestimate: screening must cover both identities and wallet addresses, and it must run before every cycle against current list versions - not just at onboarding. Programs that build layered controls with per-cycle evidence and a defined flag process can demonstrate defensible compliance under scrutiny. Programs that screen once and assume coverage thereafter carry a risk that compounds with every cycle.

‍