Crypto settlement is final. Once a payment leaves an exchange, stablecoin rail, on/off-ramp or PSP, there is usually no recall process and no overnight reversal. That changes the screening problem: the control has to run before release, while the transaction can still be stopped.
On-chain analytics handles an important part of that job. It can show whether a wallet has exposure to a mixer, sanctioned cluster, darknet market or other blockchain risk. But a clean wallet score does not answer the question a regulator or banking partner will ask after a problem: who was the customer, originator or beneficiary, and why was that party allowed through? That risk sits in the named party as well as the address. A Travel Rule payload, KYC record or payment message may carry the person or company behind the transfer, and that name still has to be checked against sanctions, PEP and adverse-media data. OFAC recorded USD 1.54bn in civil penalties and settlements in 2023, and the UK’s OFSI reported more than £37bn in frozen assets in its 2024 review.
Where ARC Comply fits
ARC Comply is the identity-screening layer beside on-chain analytics. It does not trace wallets, cluster blockchain activity or replace Chainalysis, Elliptic or a TRM-style provider. It screens the names and parties those tools do not resolve: customers at onboarding, originators and beneficiaries in Travel Rule data, and names found in payment messages or free-text fields.
On-chain tools assess the address. ARC Comply screens the identity attached to the flow.
| On-chain analytics | ARC Comply | |
|---|---|---|
| Question | Is the wallet risky? | Who is the named party? |
| Data | Blockchain transaction graph | KYC records, payment messages and Travel Rule payloads |
| Role | Address exposure and wallet behaviour | Sanctions, PEP and adverse-media screening of people and companies |
| Fit | Chainalysis, Elliptic, TRM-style providers | Complementary identity layer beside them |
What it screens
Integration can be as light or as operational as the team needs. ARC Comply can sit behind a small REST API for teams with existing workflow tooling, or provide the case-management layer compliance teams need to triage, investigate and evidence decisions. POST /api/screen screens a customer or counterparty at onboarding. POST /api/screen_transaction screens named parties in Travel Rule or payment-message data, including names that appear only in free-text narrative fields. POST /api/screen/batch supports portfolio or back-book checks at scale, before release and before settlement.
Why it is defensible
The engine is built to reduce false positives without hiding the reason for a decision. The matching logic stays visible enough for an analyst, banking partner or auditor to see why a name was treated as risk or noise.
The hard part is not finding matches. It is finding the right ones without burying analysts.
- Transliteration is handled automatically. Arabic
محمدcan resolve toMohammedorMuhammad; RussianСергейcan resolve toSergeiorSergey, without the customer submitting every spelling variant. - Rare names carry more weight than common terms. A name like
Krasnopolskymatters more than frequent words such asSmith,LimitedorTrading. - Date of birth and country reduce weak matches. A conflicting DOB can push down a coincidental namesake, but a matching DOB does not inflate a poor name match into a good one.
- Suppressions are reasoned, not hidden. A match can be held back because the evidence is weak, but the reason is still available for review.
Each result carries a breakdown: the matched name, list, risk category, score components, rule and threshold. Cases can be ranked by regulatory consequence, so a lower-confidence sanctions match can be treated as more urgent than a higher-confidence low-risk PEP or adverse-media hit. Auto-block rules can be configured for lists where pre-settlement blocking is required; low-confidence and below-threshold results remain available for human review rather than being silently cleared.
For the compliance team, the output is a decision record: which party matched, which list or risk category applied, what threshold was used, what the analyst decided and which reason code was recorded. That is the record a banking partner, auditor or regulator can reconstruct later.
Performance and proof
On dedicated multi-core hardware, ARC Comply has sustained about 20,000 names per second at single-digit-millisecond per-name latency in internal testing. It is a sizing reference, not an SLA. In production, availability and latency targets are agreed against the deployment model and workload.
For a proof-of-value, use a redacted sample of your alerts, onboarding records or payment data, then measure false positives, disposition time and audit-readiness against the current process. Nothing needs to auto-clear or auto-block until your team has set the thresholds and reviewed the results.
For information only; not legal or compliance advice. Product capabilities, including transaction screening, should be confirmed before live reliance. Benchmarks are illustrative and not an SLA; targets are agreed per engagement. OFSI/OFAC figures are attributed to those bodies. Performance may vary. © 2026 ARC Comply Ltd.