Frequently asked questions

YONA is an open standard for pre-disclosure, pre-settlement authorization between VASPs. It gives one VASP a standard way to request a clear authorization decision from another before regulated data is disclosed and before settlement begins.

YONA addresses a practical gap in interVASP payments. Existing regulations and industry systems generally do not define a distinct authorization step before sensitive customer data is disclosed and before settlement begins. Without that step, VASPs face recurring operational and compliance friction when deciding whether to proceed with a payment.

YONA standardizes one boundary: early authorization between VASPs before regulated data is disclosed and before settlement begins. That narrow scope is intentional. It lets YONA address a real interoperability problem without trying to replace the systems institutions already use for Travel Rule exchange, compliance review, custody, or settlement.

A Travel Rule network generally focuses on exchanging regulated customer data and supporting the compliance workflows around that exchange. YONA focuses on a narrower, earlier boundary: whether the beneficiary-side institution is willing to move forward before regulated data is disclosed and before settlement begins. It is designed to work alongside existing Travel Rule and compliance systems rather than replace them.

YONA is designed to work alongside existing provider relationships and internal systems. It does not require institutions to change their Travel Rule, compliance, custody, or settlement providers. It standardizes the authorization boundary that sits before those systems, not the post-authorization systems that may follow. Bilateral integrations can solve this problem for specific counterparties, but YONA is meant to provide a reusable authorization layer that does not need to be redesigned for each counterparty relationship.

Because YONA standardizes a narrower and earlier boundary. Existing providers may still handle Travel Rule exchange, compliance workflows, custody, or settlement. YONA focuses on whether the beneficiary-side institution is willing to proceed before regulated customer data is disclosed and before settlement begins. A VASP may evaluate YONA if it wants that authorization boundary to be reusable, explicit, and less bespoke across counterparties.

No. YONA is an open standard, not a YONA runtime network. It does not require a central relay, hosted messaging hub, or membership-based transport layer run by YONA. Implementations work independently with each other by adhering to normative requirements defined by YONA.

YONA defines the discovery and endpoint model required for interoperable YONA interactions. It does not attempt to solve every broader counterparty-discovery problem outside YONA’s authorization scope. It also does not define destination addresses, account identifiers, settlement instructions, or other settlement-execution details as part of that scope.

YONA is especially useful when the counterparty is not already known, but it is not limited to that case. The same authorization model can also be used with known counterparties when a firm wants a clear and standardized boundary before disclosure and settlement. The live FAQ also points to real-world friction such as beneficiary-information mismatches, blocked transfers, manual repair work, and uncertainty about counterparty handling.

Yes. YONA is intended to be open to read, implement, test, evaluate, and deploy without requiring approval, membership, contract, or a commercial relationship with YONA. It is also not a compliance certification or approval program.