What is the YONA Pilot?

The YONA Pilot is a limited path for early validation of YONA push-payment authorization behavior under yona:ruleset:v1.0.

It lets a VASP test the core YONA authorization interface before moving to a fuller implementation. The pilot covers push-payment authorization only:

• use of beneficiary_handle
• discovery of the beneficiary-side authorization endpoint
• signed authorization requests and responses
• request/response binding
• deterministic handling of ACCEPT, REJECT, and NO_RESPONSE

Testing may be performed locally or bilaterally. A live interVASP counterparty is allowed, but not required.

Completing the pilot validates push-payment authorization support only. It is not a full YONA conformance claim.

What Problem it Addresses

YONA standardizes one early question between VASPs:

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

This is most relevant when firms face counterparty uncertainty, beneficiary-detail mismatches, premature data disclosure risk, or repeated bespoke pre-transfer coordination.

What Stays Unchanged

The following remain outside YONA:

• Travel Rule data exchange
• PII disclosure
• Compliance checks
• Wallet-address handling
• Custody workflows
• Settlement execution

What a VASP Tests in the Pilot

The current pilot tests the push-payment authorization boundary only.

A VASP may test the originator-side role, the beneficiary-side role, or both. Testing may be local, simulated, or bilateral.

In practice, the pilot checks whether the implementation can:

• use beneficiary_handle in the push-payment flow
• discover the beneficiary-side YONA authorization endpoint through did:web
• send or receive a signed YONA authorization request
• return or process a signed terminal authorization response
• bind the response to the exact request through request_jws_sha256
• handle ACCEPT, REJECT, and NO_RESPONSE deterministically

The pilot documentation narrows the normative YONA requirements to this push-payment scope, so a VASP does not have to guess which parts of the full document set apply to the pilot.

What the Pilot Proves

The pilot proves that a VASP can support the scoped YONA push-payment authorization step for the tested role or roles.

It shows that the implementation can use the required identifiers, reach the correct authorization endpoint, exchange signed authorization messages, bind each response to the exact request, and produce the expected terminal outcome.

That is the point: not production settlement, not Travel Rule exchange, not full YONA conformance — just the authorization boundary.

What the Pilot Does Not Prove

The pilot does not prove full YONA conformance, including Base Interoperability Profile (BIP) support.

It does not test pull-payment flows, including payment-intent retrieval; full BIP endpoint or transport coverage; or any post-ACCEPT workflows, including Travel Rule payload exchange, settlement-instruction handling, custody workflows, settlement execution, or post-ACCEPT message transport.

A pilot-support statement means only that the scoped push-payment authorization behavior has been tested. It is not a full YONA conformance claim.

Who Should Read What Next

If you are evaluating whether to run the current pilot, read YONA Pilot next. It is the normative path for testing scoped push-payment authorization.

If you are implementing or reviewing the authorization model, read YONA Ruleset 1.0 next. It defines the message semantics, authorization behavior, and terminal outcomes.

If you are pursuing full YONA conformance, read the Base Interoperability Profile and the YONA Conformance Test Suite after Ruleset 1.0.

For examples and engineering support, use Reference Messages & DID Examples and Implementation Guidance as non-normative aids.