Contrary to the prevailing views, reading of EU, US, Singaporean, and UAE regimes side-by-side shows that the general regulatory direction appears to be solidifying. Regulators are converging on the same five questions every onchain compliance program has to answer.

They want to know when you knew about a risk and whether you can prove it, whether your monitoring runs continuously against a baseline, and whether you can show the decision and the policy behind it. They also want to know how far back and across how many chains you traced, and what your system actually did to stop a prohibited transaction. The wording and deadlines change by jurisdiction, but the underlying questions are the same.

For digital asset compliance offices, this is a major benefit as it reduces the operational complexity of transitioning between multiple jurisdictions. The questions below represent common threads that appear across the most developed digital asset legislations.

‍

Question 1: When did you know, and can you prove it?

Every regime attaches a clock to knowledge, and each clock starts at a decision you make rather than at the incident itself. Sanctions carry no window to release a hit under review. Firms can still resolve whether a match is genuine through the ordinary alert-review process, so funds are locked or held while that review is pending. Once the match is confirmed, the property is blocked and a report is due within 10 business days of the blocking. ^[1] The EU’s DORA gives four hours from the moment you classify an ICT incident as major. ^[2,3] Suspicious activity generally has a more generous bar, with a suspicious activity report required 30 days from initial detection. FinCEN is explicit that an automated alert itself doesn’t start that clock as that detection is defined by the point where a review concludes there is reason to suspect.^[4]

While triggers vary, the evidence an examiner asks you for is the same. The common thread across OFAC and FinCEN is an alert-to-decision standard: an alert is raised, the activity is classified, and that classification is what starts the clock. Set that standard with your vendor, build it into your compliance program, and log the first signal, the classification decision, and the timestamp for each. Minimizing that window depends on alert quality, meaning system-generated, auditable explanations for why an alert isn't a false positive and whether it matches existing policy. Batch processing cannot reconstruct what you knew at a particular time.

‍

Question 2: What is the baseline, and is your monitoring against it continuous?

Every developed regime frames ongoing monitoring as a comparison, which means each one is looking for a baseline you’ve measured against. FATF Recommendation 10 requires transactions to be scrutinised across the life of a relationship, confirming they stay consistent with what you know of the customer, their business and their risk profile.^[5] Article 13(1)(d) of the EU's Fourth Anti-Money Laundering Directive says much the same in the same terms.^[6] Both assume something was set at onboarding: an initial risk assessment, a customer risk profile, and the thresholds in your policies. Three obligations then measure against it, with customer due diligence tracking the entity, transaction monitoring tracking behaviour as deviation, and sanctions screening tracking the address and the geographic endpoint, where liability is strict and the answer is closer to a binary.

While each of the three looks at different data, all of them run continuously. Set the baseline deliberately at onboarding, then re-evaluate addresses you have already approved, because OFAC recommends a historical lookback once an address is designated.^[7] A point-in-time check cannot tell you whether a counterparty is still clean today.

‍

Question 3: Can you show the decision, the policy behind it, and who validated the policy?

Every regime that requires monitoring also requires you to prove the monitoring works. The Monetary Authority of Singapore wants the parameters and thresholds used to identify suspicious transactions documented and independently validated, then reviewed periodically for appropriateness.^[8] New York's Part 504 is the most prescriptive, demanding end-to-end testing that the detection logic and threshold settings map to the institution's actual risks across both AML transaction monitoring and sanctions filtering, with a senior officer or the board certifying annually and the records producible on request.^[9] Testing and auditing has been one of the five essential components of OFAC's compliance framework since 2019.^[10]

Mechanics may vary but what an examiner wants to see is the same. Log the address checked, the policy version applied, the outcome, the evidence behind it, and the validation trail for the policy itself, together with who or what dispositioned the alert (an analyst or the system approving, blocking, or escalating it) and the timestamp of that disposition. An alert queue by itself is not enough. It needs to show a policy was applied for a documented reason.

‍

Question 4: How far back, and across how many chains, did you look?

Ledger transparency raises the standard rather than lowering it, and the rules reflect that across three dimensions: depth, how far back in the transaction history you trace, breadth, how much connected exposure and which risk categories you assess, and chain coverage, whether you follow the activity across bridges and multiple chains. The Guidelines to MAS Notice PSN02 say a provider may need to "trace previous transactions of the digital payment token as far back as necessary" to judge whether circumstances are unusual, setting an obligation without setting a hop limit.^[8] Dubai's Virtual Assets Regulatory Authority (VARA) is more specific, treating an increase in the number of hops assessed in analytics as a control to tighten as risk rises, and naming cross-chain bridges as a technique for obscuring origin.^[11] However, counting hops in isolation solves nothing. Depth must be explicitly tied to a risk-based and category-based framework. OFAC has already enforced this point in its 2021 settlement with BitPay over 2,102 apparent violations where the firm had buyer information on file, including names, addresses, and IP or location data, but screened only its merchant customers and not the buyers transacting with them.^[12]

While the depth and breadth expected vary with the risk, the failure mode is consistent. BitPay had a screening program and it stopped one layer too early so set hop depth and indirect-exposure thresholds as policy parameters that scale with risk, instead of accepting a vendor default, and screen liquidity pools on the exposure of their depositors as well as the pool address itself. Direct counterparty screening will pass an address that received funds from a sanctioned entity two hops back.

‍

Question 5: What did your system actually do about it?

The newest rules are the most explicit about what has to happen after detection. The GENIUS Act requires stablecoin issuers to hold the technical capability to block, freeze and reject impermissible transactions, and to comply with a lawful order to seize, freeze, burn or prevent transfer.^[13] The joint FinCEN and OFAC proposed rule puts the objective plainly, which is to prevent a prohibited transfer rather than unwind one after settlement.^[14] Pending US market structure legislation would go further, requiring intermediaries to run risk management programmes before they route activity through a DeFi protocol, and naming blockchain analytics among the tools expected to do that work.^[15]

While the instruments differ, the test is the same. Reach an approve or deny decision fast enough to sit inside the withdrawal or signing flow, and let the policy execute without waiting on a human. Infrastructure that generates alerts for a queue answers the detection question and leaves this one open.

‍

Where they still differ, and why it matters

The regimes have not converged on everything. Only the GENIUS Act requires an issuer to hold the technological ability to comply with a lawful order, which may call for seizing, freezing, burning, or preventing transfer of its own tokens, and only for permitted payment stablecoin issuers. MiCA excludes services provided in a fully decentralized manner without any intermediary, although only in a recital and without defining the phrase,^[16] while a pending US approach puts specific illicit-finance obligations on operated DeFi front ends instead.^[15]

These differences only become a problem when they turn into arbitrage, because the perimeter changes with jurisdiction and structure. An issuer weighs jurisdictions partly on whether it has to build intervention capability at all. A DeFi business can structure activity so that obligations attach to an interface in one market but not to the underlying protocol in another. Neither of those is your problem until you screen a counterparty that took advantage of it, and at that point the history arrives in your own results.

‍

A common standard

Across all the major frameworks, screening that runs in real-time rather than in batches, evaluates indirect exposure across hops and chains rather than direct counterparties alone, resolves to a recorded approve or deny against a versioned policy, and enforces that policy automatically is the standard rather than the exception.

Hypernative has been built to this shape.  Real-time address screening, multi-hop and cross-chain exposure tracing across more than 75 networks, configurable policies pool toxicity thresholds enforced at execution, continuous re-evaluation of addresses already approved, and every decision logged with its evidence for examination. At transaction-level you’re able to simulate each transaction offchain to verify what it will actually do, then enforce your policy to approve or reject it before anything is signed, or route it to a senior signer where the rules require review, all while we watch all events 24/7 and triggering automated onchain actions when a threshold or rule is met.

More than 350 organizations run on the platform, with a false positive rate at 0.001%, which is the precondition for automating enforcement rather than merely recommending it.

Learn more about Hypernative’s Compliance Solutions.

‍

References

1. OFAC FAQ 49, on 31 CFR 501.603 and 501.604. https://ofac.treasury.gov/faqs/49
2. Regulation (EU) 2022/2554 (DORA), Article 19. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
3. Regulation (EU) 2025/301, Article 5. https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng
4. 31 CFR § 1020.320(a)(3). https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1020/subpart-C
5. FATF, International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation, Recommendation 10. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
6. Directive (EU) 2015/849 (Fourth Anti-Money Laundering Directive), Article 13(1)(d). https://eur-lex.europa.eu/eli/dir/2015/849/oj/eng
7. OFAC, Sanctions Compliance Guidance for the Virtual Currency Industry, October 2021. https://home.treasury.gov/system/files/126/virtual_currency_guidance_brochure.pdf
8. MAS Notice PSN02, paragraphs 6.24 to 6.26, and the Guidelines to MAS Notice PSN02, chapters 6-10 and 6-11. https://www.mas.gov.sg/-/media/amld-amendments---30-june-2025/mas-notice-psn02.pdf
9. 23 NYCRR Part 504, Banking Division Transaction Monitoring and Filtering Program Requirements and Certifications. http://www.dfs.ny.gov/legal/regulations/adoptions/dfsp504t.pdf
10. OFAC, A Framework for OFAC Compliance Commitments, May 2019. https://ofac.treasury.gov/media/16331/download?inline=
11. VARA, AML/CFT Business Risk Assessment Guidance, drawing on the 2026 thematic review. https://media.umbraco.io/dwtc/thylprns/vara-amlctf-business-risk-assessment-guidance.pdf
12. OFAC settlement with BitPay, Inc., 18 February 2021. https://ofac.treasury.gov/recent-actions/20210218
13. GENIUS Act, Public Law 119-27. https://www.congress.gov/bill/119th-congress/senate-bill/1582/text
14. FinCEN and OFAC joint proposed rule, 10 April 2026. https://www.federalregister.gov/documents/2026/04/10/2026-06963/permitted-payment-stablecoin-issuer-anti-money-launderingcountering-the-financing-of-terrorism
15. H.R. 3633, Digital Asset Market Clarity Act of 2025, 119th Congress. https://www.congress.gov/bill/119th-congress/house-bill/3633 (as of this week, still pending in the Senate, not yet law, so "pending" is the right word to keep in the text)
16. Regulation (EU) 2023/1114 (MiCA), Recital 22. https://eur-lex.europa.eu/eli/reg/2023/1114/oj/eng

‍

‍

‍