Crypto custody & compliance · engineering reference
Compliance is transaction architecture. The decisive question is whether a gate runs before credit and before signing, with enough versioned evidence to reproduce the decision months later.
Most compliance failures are not missing policies. They are gates placed at the wrong point in the call graph, where they can observe a problem but no longer stop it. This sheet is about placement.
Before signing, never after broadcast. Screening a transaction you have already sent is not a control, it is a report, because the only action left is a filing.
It is the requirement that identifying information about the sender and the recipient travels alongside a transfer between regulated firms, above a threshold. IVMS101 is the shared data format that information is carried in.
The payload is standardised and the network is not. The competing Travel Rule networks all carry IVMS101 but discover and authenticate counterparties differently, so you either join several of them or route through a broker.
Sanctions lists move in both directions. An address that is clean today can be designated tomorrow, and the exposure applies to what you already did, so screening only at onboarding leaves a gap that grows every day.
If you remember one lineCompliance controls are pipeline placement decisions, not a checklist. Screen before irreversibility.
Gate placement is the whole design. A control that runs after signing is forensics, not compliance.
Parse chain, contract, transfer identity and finality.
KYT + sanctions with model/list version.
Customer, counterparty VASP, corridor, unhosted status.
Minimum IVMS101 data to authenticated counterparty.
Ledger intent, policy, velocity, approvals.
Only the exact cleared payload.
Signing is the boundary. “Screen before broadcast” is too late if valid signed bytes already exist.
Five gates run before the sixth. Once valid signed bytes exist, every remaining control is after the fact.
Parse chain, contract, amount, source, destination, tag, and finality before any customer posting.
Concrete use: Open a compliance case on a new USDC transfer while the balance remains pending.
Failure mode: Screening after credit lets tainted value fund internal trades or withdrawals.
Screen the actual transfer and counterparty exposure before making funds available.
Concrete use: Persist provider, model/list version, score, categories, hop depth, and raw response hash.
Failure mode: A naked score cannot be reproduced after the vendor model changes.
All identity, Travel Rule, sanctions, destination, and business-policy checks must pass before irreversible signing.
Concrete use: The signer callback verifies compliance case case_20418=cleared and exact destination bytes.
Failure mode: Screening between signing and broadcast leaves a valid signed payload that can escape.
Addresses and persons previously clean can become blocked property when lists change.
Concrete use: Subscribe to list changes, rescreen held positions and pending transfers, and open retroactive cases.
Failure mode: A once-at-onboarding result silently expires.
Provider outage blocks automated value movement while an explicit, dual-controlled manual route handles exceptions.
Concrete use: After 60 seconds of KYT timeout, queue rather than sign; page operations before SLA breach.
Failure mode: Fail-open turns the outage into an ideal attacker window.
The control boundary is signing. A signed blockchain transaction is a bearer-like capability even if your broadcaster has not submitted it yet.
| Path | Gate | Input | On hit | If placed later |
|---|---|---|---|---|
| Deposit | Asset validation | chain + contract + decimals | Quarantine | Fake token may be credited |
| Deposit | KYT exposure | source + transfer graph | Pending/manual review | Funds become internally spendable |
| Deposit | Sanctions | person + address + live list | Block/segregate | Blocked property may move |
| Deposit | Finality | chain-native status | Wait | Reorg creates unbacked credit |
| Withdrawal | Customer/KYC state | identity + account risk | Reject/review | Value enters signer path |
| Withdrawal | Travel Rule | counterparty + threshold + IVMS payload | Hold/send data | Transfer may breach obligation |
| Withdrawal | Destination KYT | address + asset + amount | Reject/review | Signed transaction exists |
| Withdrawal | Policy callback | ledger intent + decoded payload | Do not sign | Broadcast control is too late |
This is a routing register, not a legal threshold table. Thresholds and scope depend on entity, activity, corridor, and current local implementation; resolve them in maintained policy data before launch.
| Regime | Engineering baseline | De minimis posture | Unhosted-wallet concern | Primary text |
|---|---|---|---|---|
| FATF R.16 | Originator/beneficiary information; VASP-to-VASP transmission | Countries implement locally | Risk-based treatment | FATF |
| United States | 31 CFR / FinCEN funds-transfer rules and BSA records | Thresholds depend on rule and transaction class | Identify applicable counterparty/rule | eCFR Title 31 |
| European Union | Regulation 2023/1113 applies information duties to crypto transfers | No general crypto de minimis | Self-hosted interactions require risk controls | EUR-Lex |
| United Kingdom | Money Laundering Regulations + FCA implementation | Verify current UK requirements | Risk-based evidence | FCA |
| Switzerland | AMLA/AMLO-FINMA implementation | Verify current Swiss threshold | Proof of control often material | FINMA |
| Singapore | Payment Services Act / MAS notices | Verify current notice and scope | Counterparty due diligence | MAS |
| Japan | Act / JFSA and JVCEA implementation | Verify current local rule | Counterparty controls | JFSA |
| Canada | PCMLTFA / FINTRAC virtual-currency transfer records | CAD threshold rules vary by duty | Identity and records | FINTRAC |
| Australia | AML/CTF regime and AUSTRAC guidance | Verify reforms and commencement | Counterparty and ownership risk | AUSTRAC |
| Hong Kong | AMLO VASP regime | Verify current threshold and circulars | Risk-based controls | SFC |
| UAE | Federal plus competent-authority rule | Depends on regulator/free zone | Counterparty verification | VARA |
IVMS101 standardizes identity data; it does not standardize discovery, transport, certificate trust, or corridor policy.
| Object / field | Cardinality / type | Constraint | Common rejection |
|---|---|---|---|
| originator / beneficiary | 1 object | Person arrays + account number | Flattening all persons into one name |
| naturalPerson.name | 1..n | Structured nameIdentifier | Single free-text full name |
| legalPerson.name | 1..n | Legal-person identifier structure | Using natural-person fields |
| nameIdentifierType | code | Controlled vocabulary such as LEGL | Unrecognized local code |
| geographicAddress | 0..n | Typed address + ISO country | Country name instead of alpha-2 code |
| addressType | code | Controlled vocabulary | Billing/home/business semantics mixed |
| nationalIdentification | 0..1 | Identifier + type; authority where required | Sending raw document without type |
| dateAndPlaceOfBirth | 0..1 | ISO date + place | Locale-formatted date |
| customerIdentification | 0..1 | VASP customer identifier | Reusing government ID |
| accountNumber | 0..n strings | Chain/account or internal account | Dropping memo/tag |
| originatingVASP / beneficiaryVASP | 0..1 | Legal-person identity | Trusting a domain name as identity |
| transferPath | 0..1 | Ordered intermediaries | Losing sequence |
| payloadMetadata | 0..1 | Encoding/transliteration metadata | No Latin/local script strategy |
Illustrative transport envelope: validate against the counterparty network's current IVMS101.2023 schema and required jurisdictional fields. Names use structured identifiers; dates use ISO 8601.
{
"originator": {"originatorPersons": [{"naturalPerson": {
"name": [{"nameIdentifier": [{"primaryIdentifier": "Rivera", "secondaryIdentifier": "Elena", "nameIdentifierType": "LEGL"}]}],
"geographicAddress": [{"addressType": "HOME", "streetName": "740 Market Street", "townName": "Denver", "countrySubDivision": "CO", "postCode": "80202", "country": "US"}],
"nationalIdentification": {"nationalIdentifier": "CUST-78421", "nationalIdentifierType": "CUST"},
"customerIdentification": "cust_78421", "dateAndPlaceOfBirth": {"dateOfBirth": "1987-04-12", "placeOfBirth": "Santa Fe, US"}
}}], "accountNumber": ["acct_78421"]},
"beneficiary": {"beneficiaryPersons": [{"legalPerson": {
"name": [{"nameIdentifier": [{"legalPersonName": "Northwind Components LLC", "legalPersonNameIdentifierType": "LEGL"}]}],
"geographicAddress": [{"addressType": "BIZZ", "streetName": "1650 Blake Street", "townName": "Denver", "countrySubDivision": "CO", "postCode": "80202", "country": "US"}],
"nationalIdentification": {"nationalIdentifier": "20261234567", "nationalIdentifierType": "RAID", "registrationAuthority": "RA000602"}
}}], "accountNumber": ["0x2B7C...91E4"]},
"originatingVASP": {"originatingVASP": {"legalPerson": {"name": [{"nameIdentifier": [{"legalPersonName": "Origin VASP Inc", "legalPersonNameIdentifierType": "LEGL"}]}]}}},
"beneficiaryVASP": {"beneficiaryVASP": {"legalPerson": {"name": [{"nameIdentifier": [{"legalPersonName": "Destination VASP Ltd", "legalPersonNameIdentifierType": "LEGL"}]}]}}},
"transferPath": {"transferPath": [{"sequence": 0, "account": "acct_78421"}, {"sequence": 1, "account": "0x2B7C...91E4"}]},
"payloadMetadata": {"transliterationMethod": ["none"]}
}Indirect exposure is a policy parameter; at enough hops almost every liquid address becomes connected.
Concrete use: Store direct and 1-hop exposure separately and require a documented threshold by category.
Failure mode: Treating graph distance as moral certainty creates unbounded false positives.
Attribution and clustering are models, not shared facts.
Concrete use: Route a high-value disagreement to evidence review; retain each vendor's label version.
Failure mode: Averaging opaque scores does not create truth.
Lists add and remove identifiers; application code must consume versioned authoritative data.
Concrete use: Treat the OFAC SDN feed as an external signed/versioned input and rescreen on update.
Failure mode: Hard-coded addresses become wrong in both directions.
Freeze and segregate; route reporting, recordkeeping, and legal decisions to the applicable program.
Concrete use: Open one case linking asset, list version, timestamps, owners, decisions, and reports.
Failure mode: Automatically returning funds may itself be prohibited.
Transmit required identity data only to an authenticated counterparty under a recorded lawful mechanism.
Concrete use: Encrypt in transit and at rest, separate compliance payload from chain transaction, and expire unnecessary copies.
Failure mode: The blockchain is not a place for Travel Rule personal data.
Deadlines are jurisdiction- and program-specific. The runbook must link to maintained legal policy, never freeze a number in application code.
Failures that pass a vendor demo. Expand each for the control and the reason it fails.
The irreversible action already happened.
Concrete use: Gate before signing.
Failure mode: A broadcaster hold does not neutralize signed bytes.
Sanctions state changes without software releases.
Concrete use: Consume authoritative versioned feeds.
Failure mode: Delisting is as important as designation.
A vendor's risk score encodes taxonomy and model choices.
Concrete use: Store evidence, category, distance, model and appeal path.
Failure mode: Threshold tuning without false-positive measurement is guesswork.
Correct IVMS data sent to the wrong VASP is a breach.
Concrete use: Verify certificate/entity before payload transmission.
Failure mode: Protocol membership is not universal identity assurance.
Recheck each vendor's public documentation before procurement. This compares integration shape, not quality, experience, or rank.
| Provider | Documented surface | Retain | Do not infer |
|---|---|---|---|
| Chainalysis | APIs and platform workflows | category, exposure, score, evidence/version | Cross-vendor score equivalence |
| TRM Labs | APIs and case workflows | risk indicators, attribution, graph context | Attribution immutability |
| Elliptic | Wallet/transaction screening APIs | risk rule, category, path, timestamp | Identical taxonomy |
| Merkle Science | Transaction-monitoring APIs | rule hit, exposure, model state | Score as legal conclusion |
| Crystal | Blockchain-analytics APIs | entity/category and transaction evidence | Universal chain/token coverage |
The payload is standardized more broadly than transport and discovery. Multi-network routing, receipts, retries, and counterparty identity are first-class state.
| Protocol/network | Transport/discovery | Identity trust | Payload | Architecture implication |
|---|---|---|---|---|
| TRISA | Certificate-backed directory/messaging | VASP certificates | IVMS101-compatible | Operate certificate lifecycle and discovery |
| TRP | Open protocol specifications | Implementation-dependent counterparty verification | IVMS101 mapping | No universal directory |
| OpenVASP | Open messaging/identity design | Protocol-defined VASP identity | Structured Travel Rule data | Reach may require another network |
| Commercial broker | Vendor directory and routed transport | Vendor onboarding model | Often IVMS101 | Broker concentration and exit are controls |
Operational and volatile claims were checked against these first-party documents on 2026-08-31. Examples are illustrative controls, not legal, investment, or vendor-selection advice.