The FinCEN MEXC Order: What Covered Institutions Must Prove by December 10

TL;DR

• FinCEN issued a final order under section 9714 finding MEXC Global a financial institution of primary money laundering concern tied to Russian illicit finance, and prohibiting covered financial institutions from any transmittal of funds from or to MEXC Global.
• The order was published in the Federal Register on November 10, 2026 and takes effect December 10, 2026, with no cessation date. That’s 27 days from today.
• There is no fine. The exposure is willful-violation penalties under 31 U.S.C. 5321 and 5322 — plus the operational cost of proving you can actually stop value from moving to and from one exchange across rails you don’t fully control.
• FinCEN wrote a reject-instead-of-return lane into the order for inbound CVC, which tells you everything about how hard address-level blocking is in practice.

FinCEN didn’t fine MEXC Global. It deleted it.

On November 6, 2026, as part of Treasury’s Operation Economic Outcast, FinCEN issued an order effectively cutting the convertible virtual currency exchanger off from the U.S. financial system. Four days later the Federal Register published it as document 2026-22962. On December 10, 2026, the prohibition goes live and does not expire.

For a BSA/AML team, this is a different species of problem than a consent order. A consent order tells you what you did wrong and gives you a remediation roadmap. A section 9714 transmittal prohibition tells you to stop routing value to a named entity, hands you a hard date, and leaves the engineering to you.

What the order actually does

The order itself runs 24 pages. The operative language is one sentence: “A covered financial institution is prohibited from engaging in any transmittal of funds from or to MEXC Global.”

Everything difficult sits in the definitions.

The order also names the MEXC entity perimeter explicitly: MEXC Global Ltd and MX Global Ltd in Seychelles, MEXC Estonia OÜ, GIDA Technology AG in Switzerland, MXC Global Ltd in the United Kingdom, the former Singapore entities, and any successor entities. Corporate family, not one registration.

The numbers FinCEN relied on

FinCEN’s findings rest on blockchain analysis covering May 2021 through May 2026. These are the agency’s figures, not estimates:

FinCEN also noted that as of December 2025 MEXC held about nine percent of global centralized CVC exchange market share, putting it among the top 20 by trading volume. That scale is why the order matters beyond the entity: a top-20 exchange is a counterparty that shows up in payment chains, OTC flow, and wallet clustering whether or not anyone intended to touch it.

The order’s own regulatory-arbitrage evidence is worth reading closely. FinCEN cites the Seychelles Financial Services Authority’s May 26, 2026 enforcement action against MX Global Ltd for unlicensed virtual asset services, a Hong Kong SFC warning from March 2024, and a Japanese FSA notice. Three regulators in three jurisdictions flagged the same platform for operating without a license. That is a decent proxy for what a vendor due diligence file should have caught.

A name on a list is not a control

Here’s the part that separates institutions that will pass an exam question on this order from institutions that will actually comply.

Sanctions screening is built to catch names in message fields. The MEXC order is about transmittals, and a CVC transmittal frequently carries no counterparty name at all — it carries a blockchain address. If your only control is a name-screening rule for “MEXC,” you have covered the wire leg and missed the token leg.

FinCEN says as much in the order’s cost-benefit discussion. It concedes “there are few, if any, readily available ways for covered financial institutions to ‘reject’ incoming CVC transactions (prior to receipt),” because CVC payment systems “limit the control of specific financial institutions over transactions.” That is a regulator acknowledging the rails push value at you.

So the order provides a rejection path instead of a hard return requirement. A covered institution that receives CVC from or originating at MEXC Global may reject it under limited circumstances — where, for example, the transfer sat in an unhosted wallet for an extended period, or where the institution’s risk mitigation procedures would preclude sending funds back to MEXC.

That flexibility is generous. It is also the most likely place for a program to drift, because “we can reject it” quietly becomes “we’ll decide case by case” becomes “nobody documented the decision.”

The decision that needs a written answer before December 10

Every covered institution touching CVC needs one documented position, approved by someone with authority, covering inbound value:

The trap in row three is real and it will generate exam findings. An unhosted wallet that received from MEXC and later sends to your institution creates indirect exposure with no name anywhere in your data. If your analytics tool isn’t tagging MEXC addresses at the cluster level, you will not see it, and “we screened the name” will not be an acceptable answer.

Who owns this

The order doesn’t assign internal ownership, so name it yourself. A workable split:

• BSA/AML Officer — owns the order response, the written reject/return procedure, and the SAR interplay.
• Payments and digital-asset operations — owns the technical block on outbound transfers and the quarantine workflow for inbound.
• Blockchain analytics / screening owner — owns address-level tagging, cluster coverage, and tuning to avoid a false-positive flood on common addresses.
• Third-party risk — owns notice to custody providers, wallet infrastructure vendors, and any partner whose rails touch MEXC, plus the contract language that obligates them to block.
• Compliance testing (second line) — owns the sample test proving the block works, executed before December 10 and again in Q1.

One trap: assigning this to “sanctions screening” alone. The block is a payment-control change, and payment-control changes fail in operations, not in policy documents.

The SAR and OFAC overlay

Two obligations survive the order untouched, and the order says so explicitly.

First, the BSA still applies in full, including SAR filing. A blocked or rejected MEXC transfer is frequently also a reportable event — especially where the customer kept trying after being told, or where the inbound value traced to Iranian or DPRK exposure. The Iran-facing Khums charity alert from earlier in Operation Economic Outcast ran through the same Iran exposure that shows up in this order’s findings. Document the SAR decision for each rejected transmittal, including the “no SAR” calls. Examiners ask for the negative decisions as often as the filings.

Second, OFAC obligations are unaffected. If a transmittal involves blocked property or an SDN, OFAC’s blocking and reporting rules control, and the order notes that a compliant OFAC block satisfies the special measure. MEXC exposure and OFAC exposure overlap but are not the same control, and conflating them produces either double-blocking confusion or a gap.

There’s also a quiet interaction with the earlier section 9714 proposal. The A7 Network rule proposed a prohibition framework built around sub-agents and notice duties; MEXC is a final order against one named exchange with a hard date. If your institution built A7 readiness around a nonpublic sub-agent list, check whether that design also blocks a named exchange at the address level. Different problem, overlapping plumbing.

30/60/90, anchored to a real date

The deadline is December 10, so the standard 30/60/90 collapses. Here’s the version that fits.

Days 1–7 (by November 20)

• Confirm whether your institution is a covered financial institution under 31 CFR 1010.100(t). Get legal’s answer in writing.
• Inventory every rail where MEXC can appear: wires, ACH, card, CVC deposit and withdrawal, OTC desk, custody, and partner-bank flows.
• Pull the entity list from the order into screening and analytics as a named cluster, including successors.

Days 8–20 (by November 30)

• Implement the outbound block and test it with a live or sandbox transaction per rail. Screenshot the block, the alert, and the log entry.
• Write the inbound reject-versus-quarantine procedure. Get BSA Officer and legal sign-off.
• Issue notice to vendors and partners whose rails touch MEXC. Give them a response deadline, not a courtesy heads-up.

Days 21–27 (by December 9)

• Run a second-line sample test across rails. Minimum: one outbound attempt, one inbound receipt, one unhosted-wallet exposure case, one customer-initiated escalation.
• Update the AML/CFT risk assessment with the MEXC finding, the exposure estimates, and the residual risk rating.
• Brief the risk committee with the date, the controls, and the two open items you’re accepting.

Post-effective (December 10 onward)

• Log each rejection and each quarantine case. Track reject rate and false positives weekly for the first month; address-level rules over-trigger on shared infrastructure.
• Add a standing quarterly test to the compliance calendar so this doesn’t become a one-time project that rots.

What good evidence looks like

The exam question in 2027 will not be “did you read the order.” It will be “show me it worked.” Five artifacts cover most of it:

1. A written applicability memo concluding covered or not covered, with the 31 CFR 1010.100(t) analysis.
2. Screening and analytics configuration showing the MEXC entity cluster and associated addresses loaded, with a version or change ticket.
3. Block test results per rail, with dates, transaction references, and the operator who ran them.
4. The reject/return procedure, signed, including the unhosted-wallet scenario.
5. Vendor notices and responses, tracked to closure.

If those five exist and are current, the order is handled. If any one is missing, the institution is relying on a name-screening rule and a hope.

Every one of those artifacts is an issue with an owner, a due date, and a validation standard. Track them that way rather than in a project spreadsheet that dies in February — the Issues Management Tracker & Template has a regulatory findings tab built for exactly this: regulator reference, management response, committed date, and closure validation with evidence.

The takeaway

FinCEN’s MEXC order is a hard-date test of whether a BSA/AML program can enforce a prohibition on rails it doesn’t fully control. The institution that treats December 10 as a screening-list update will be able to show a rule and nothing else. The institution that treats it as a payment-control change — with a written reject/return decision, tested blocks per rail, and vendor obligations — will have something to hand an examiner.

Twenty-seven days is enough time. It is not enough time to start in December.

Related: FinCEN’s A7 Network rule and sanctions screening techniques that cut false positives.