YONA with Existing Travel Rule Providers
YONA is designed to work alongside existing Travel Rule and compliance providers.
It does not require institutions to replace those relationships.
What YONA standardizes
YONA standardizes one earlier boundary:
whether the beneficiary-side institution is willing to proceed before regulated customer data is disclosed and before settlement begins.
What remains outside YONA
Travel Rule payloads, compliance messaging, custody, settlement instructions, settlement execution, and local compliance policy remain outside YONA.
Those steps stay with the systems and providers institutions already use.
Why evaluate YONA if current tooling already works?
A VASP may still evaluate YONA if it wants:
- a reusable pre-transfer authorization boundary across counterparties
- a clearer separation between early authorization and later regulated-data exchange
- a way to reduce bespoke pre-transfer coordination without replacing later providers
- a standard path for cases involving counterparties that were not already known
What YONA is not asking you to do
YONA is not asking you to replace your Travel Rule provider.
YONA is not asking you to move post-authorization compliance or settlement into YONA.
YONA is not asking you to join a YONA runtime network.
How to evaluate it
Start with Pilot Overview for the current lower-lift path.
If the pilot is relevant, move to YONA Pilot for the current normative pilot scope under yona:ruleset:v1.0.
Engineers should then use YONA Ruleset 1.0, Reference Messages & DID Examples, and Implementation Guidance as the implementation reading path.
Teams pursuing full conformance should then read Base Interoperability Profile (BIP) and the YONA Conformance Test Suite.