Purpose
The Travel Rule Configurator converts an operating footprint into a structured configuration covering corridors, thresholds, required originator and beneficiary information, counterparty readiness, transmission policy, and retained evidence.
It supports configuration and change analysis. It does not replace current legal interpretation or the institution's obligation to confirm which requirements apply to a specific transaction and entity.
Configuration inputs
| Input | Example decision |
|---|---|
| Entity and licence | Which regulated entity is executing the transfer? |
| Origin and destination | Which jurisdictions and corridor are involved? |
| Asset and network | Which asset, chain, or payment rail applies? |
| Transaction value | Which threshold and aggregation treatment applies? |
| Counterparty type | Hosted VASP, unhosted wallet, bank, or unknown counterparty? |
| Partner capability | Which protocol and data fields can the counterparty exchange? |
| Risk policy | Which cases require hold, review, reject, or escalation? |
Configuration lifecycle
- Define the operating perimeter and regulated entities.
- Map corridors and applicable requirement sources.
- Configure thresholds, aggregation rules, and data fields.
- Define counterparty and wallet handling.
- Select transmission and fallback routes.
- Test positive, negative, boundary, and exception cases.
- Approve and publish a versioned configuration.
- Reassess the configuration when obligations, corridors, or partners change.
Outputs
- Jurisdiction and corridor matrix.
- Threshold and aggregation configuration.
- Required and conditional data fields.
- Counterparty capability and fallback rules.
- Test scenarios and expected outcomes.
- Versioned configuration export.
- Change log and approval evidence.
Counterparty readiness
Counterparty readiness is more than registry presence. The operating team should know whether the counterparty can be identified, which exchange method it supports, whether the required fields can be transmitted, and what happens if information is rejected or delayed.
Review conditions
Route a transfer for review when the configured facts are incomplete, contradictory, outside the approved corridor, or dependent on an unconfirmed counterparty capability. Do not silently default an unknown condition to the least restrictive outcome.
Change management
Every material change should create a new configuration version. Link the version to the underlying requirement, test cases, approval, effective date, and impacted products or corridors.