About YONA

YONA standardizes one early question:

Can this payment move forward on the beneficiary-side before regulated customer data is disclosed and before settlement begins?

A sending institution may need beneficiary-side confirmation before disclosing regulated customer data or beginning settlement, especially when the counterparty is not already known.

Without a standard authorization boundary, firms often rely on bespoke coordination, manual repair work, or early disclosure before readiness is clear.

It does not replace existing Travel Rule exchange, compliance review, custody, or settlement arrangements.

That narrow scope is intentional. It lets institutions evaluate a specific interoperability boundary without replacing the systems that come afterward.

Implementations do not require a YONA runtime service, central relay, or membership-based messaging layer.

Institutions interact directly using published discovery information, service endpoints, and signed messages, according to the normative requirements defined by YONA releases.

Under YONA, interoperable implementations use DID-based discovery, signed JWS messages, exact request/response binding, and a defined conformance baseline.

That is deliberate. YONA is meant to be reused across institutions, not interpreted loosely.

Start with Pilot Overview to evaluate the current pilot for push-payment authorization flows.

Use YONA Ruleset 1.0 to evaluate full YONA conformance, including both push-payment and pull-payment flows.