Payment Messaging

For a shielded MIP410 payment, the sender virtual asset service provider (VASP) delivers encrypted payment data to the recipient VASP. The recipient VASP inspects the payment, applies its policy, and prepares the proofs for acceptance or rejection. Institutions also use messaging to meet their Travel Rule obligations. For covered payments using either MIP20 or MIP410, the participating financial institutions (FIs) exchange the required originator and beneficiary information to identify the parties and perform compliance checks.

​

FI-to-FI payment initiation

The payment initiation message carries the sender FI’s instruction and the references the recipient FI uses to process the payment. The ISO 20022 message catalogue defines pacs.008 for FI-to-FI customer credit transfers and pacs.002 for payment status reports. For MIP20, a send policy contract can require evidence of the FI’s decision. It authenticates that evidence and checks that the decision permits the payment before calling MIP20 to transfer funds. Any FI response required before execution forms part of the integration’s offchain preparation. Send and Receive Policies explains how these checks are enforced. For MIP410, initiatePayment creates a hold that reserves the sender’s notes. The recipient VASP can then receive and check the payment data before submitting acceptance or rejection. The integration determines message delivery order relative to hold creation. MIP410 encodes the payment payload in two encrypted parts. The note memo contains the recipient note opening, payment effect, payment nonce, and hold deadline. The institutional payload contains the payment identifiers, optional Travel Rule record, sender VASP identifier, sender payload signature, and payload salt seed. The recipient VASP decrypts the note memo with the recipient’s incoming viewing key and the institutional payload with its own messaging secret key. The recipient VASP combines both decrypted parts and recomputes the payload commitment from the payment, payment identifiers, and optional Travel Rule record, binding them to the hold. The encrypted payment envelope defines these formats. Delivery, endpoint discovery, retries, and status messages remain integration responsibilities.

​

FI-to-FI Travel Rule exchange

The Travel Rule record carries originator, beneficiary, and institution information associated with the payment. Applicable law determines the required information and each institution’s obligations. The FATF virtual-asset framework includes obtaining, holding, and securely transmitting originator and beneficiary information. IVMS101 supplies a data model. The messaging integration determines the transport channel. For MIP20, institutions exchange the record offchain. A send policy contract can verify a commitment or signed decision. The contract defines the evidence format, authenticates its signer, and binds it to the exact payment. Evidence supplied as calldata is public, so private identity records stay offchain. For MIP410, payment identifiers and the optional Travel Rule record travel together in the encrypted institutional payload. The sender VASP prepares any included record before initiatePayment commits it to the hold. The recipient VASP recomputes the payload commitment from the decrypted note memo and institutional payload, verifies the sender VASP’s payload signature, and checks the information its policy requires before acceptance. Access to the recipient’s incoming viewing key alone does not reveal the institutional payload. A record’s presence does not establish that every required field is populated, that its values are accurate, or that the named beneficiary matches the shielded recipient. MIP410’s reference record-threshold policy checks presence for payments at or above its configured threshold. It does not check those further claims. IVMS evidence defines the committed fields.

​

Delivery, processing, and failure

Delivery and settlement have separate outcomes: For MIP20, a send policy contract can revert when required evidence is missing or invalid. The receive policy contract can also refuse a credit under the recipient’s stored rules. REVERT mode rolls back an ordinary transfer. QUARANTINE mode completes the transfer to escrow and records its recovery authority. Refused mints, MIP20 hold captures, and payouts from a token’s own balance always quarantine. For MIP410, a finalized, successful initiatePayment transaction establishes the hold. It remains pending until acceptance, rejection, or expiry followed by reclaim. Acceptance proves the configured policy checks passed. It does not by itself prove delivery, decryption, or retention of a Travel Rule record. MIP410 handles delivery and resolution failures as follows: Rejection requires the recipient note opening and payment effect as private proof inputs even when the rejection policy permits an absent institutional payload. If those inputs remain unavailable, expiry and reclaim release the input locks. Payment resolution defines the proofs and state transitions.

​

Authenticity, integrity, and responsibility

For MIP20, the send policy contract verifies signed evidence against the signers configured by the institution. Its signed format must bind the chain ID, verifying contract, token, sender, recipient, amount, nonce, and deadline. The contract reconstructs the digest and checks expiry and prior use. A token transfer authorization does not authenticate separately supplied FI evidence. For MIP410, the sender VASP signs the payload commitment with its messaging secret key. The recipient VASP verifies that signature against the messaging public key in the pool’s institution registry. A separate signature authorizes each policy decision and is verified inside the policy wrapper. Once a hold is created, its payload commitment cannot be amended. The sender VASP can resend the committed information, including with fresh encryption. Adding an absent Travel Rule record or changing a committed field produces a different commitment and requires a new payment. Rejection or reclaim releases the existing hold’s reserved notes for reuse. MIP410 authenticates messaging keys through the pool’s institution registry. Its payment proofs do not establish X.509 credentials or legal entity identifier (LEI) authentication. Counterparty identity verification and due diligence remain institutional responsibilities.