> ## Documentation Index > Fetch the complete documentation index at: https://docs.metalntwx.com/llms.txt > Use this file to discover all available pages before exploring further. # Payment Messaging > FI-to-FI payment initiation, Travel Rule exchange, and message delivery and authentication 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](https://www.iso20022.org/catalogue-messages) defines `pacs.008` for FI-to-FI customer credit transfers and `pacs.002` for payment status reports. | Topic | Explanation | | - | - | | Information | Recipient details, asset, amount, and payment references. MIP410's payment identifiers are the unique end-to-end transaction reference (UETR), end-to-end identifier, remittance information, and purpose code. | | When | Before the recipient FI makes the payment decision that depends on the instruction. The integration defines the exchange's timing relative to onchain execution. | | Participants | Sender FI and recipient FI. | | Prerequisite for | The recipient FI's assessment and processing of the payment. Settlement requires successful execution under the applicable onchain policy. Neither MIP20 nor MIP410 parses a complete `pacs.008` message. | | After receipt | The recipient FI authenticates the sender FI, validates the instruction, matches it to the payment, and performs the checks needed for its decision. | 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](https://docs.metalntwx.com/learn/mip20/handlers-and-policy.md) 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](https://docs.metalntwx.com/reference/privacy/transfer-circuit.md#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](https://www.fatf-gafi.org/en/topics/virtual-assets.html) includes obtaining, holding, and securely transmitting originator and beneficiary information. | Topic | Explanation | | - | - | | Information | Originator and beneficiary identity and account fields, plus originating and beneficiary VASP identifiers. MIP410 supports fields mapped to IVMS101. | | When | Timing follows applicable Travel Rule requirements. Each FI obtains and checks the information on which its authorization depends before authorizing the payment. | | Participants | Sender FI and recipient FI, each responsible for its side of the exchange and its retained records. | | Prerequisite for | Meeting the applicable Travel Rule obligations. An FI can also require a send policy contract to verify evidence before transferring funds, or require evidence in its registered MIP410 policy. | | After receipt | The recipient FI authenticates the source, matches the record to the payment, checks the required fields under its rules, and retains the record and its decision. | 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](https://docs.metalntwx.com/reference/compliance/ivms-evidence.md) defines the committed fields. ## Delivery, processing, and failure Delivery and settlement have separate outcomes: | Outcome | What it establishes | | - | - | | Receipt acknowledgement | The receipt condition agreed between the institutions, such as accepting bytes for processing. MIP410 has no built-in delivery acknowledgement format or receipt check. | | Validated payment information | The recipient FI has authenticated and checked the instruction and required records against the payment. These checks run offchain. | | Policy approval | The payment passed the policy checks enforced during execution. A send policy contract checks outgoing rules and required evidence before calling MIP20. The token calls the receive policy contract to check the recipient's stored rules. MIP410 uses policy-wrapper proofs for the sender VASP's approval at initiation and the recipient VASP's approval at resolution. | | Finalized delivery | The expected MIP20 credit reached the intended recipient in a finalized transaction, or a successful MIP410 `acceptPayment` finalized. A MIP20 credit to quarantine is a separate outcome. | 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: | Failure | Handling | | - | - | | Missing, unreadable, or mismatched payload | The recipient VASP cannot complete payload validation. The sender VASP can redeliver data matching the hold's payload commitment while the hold remains active. | | Duplicate delivery | Repeated delivery does not change the hold. Duplicate detection in messaging remains an integration responsibility. The pool resolves each hold only once. | | Missing information required by policy | Acceptance cannot satisfy that policy. The recipient VASP may reject if it can produce the recipient proof and policy-wrapper proof for rejection. | | Invalid proof or failed resolution transaction | The failed attempt leaves the hold unchanged. The same deadline and protocol checks apply to subsequent attempts. | | Expired hold | Acceptance and rejection are no longer available. Anyone can call `reclaimExpired` to release the sender's input locks. Expiry alone does not release them. | 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](https://docs.metalntwx.com/reference/privacy/transfer-circuit.md#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. | Property | What establishes it | Boundary | | - | - | - | | Sender VASP authentication | The payload signature verifies under the sender VASP's messaging public key in the pool's institution registry. | The registered key authenticates the signer. Counterparty due diligence remains an institutional responsibility. | | Content integrity | The recipient VASP recomputes the payload commitment and compares it with the value stored on the hold. | The binding covers the defined payload fields. It does not establish conformance of an entire ISO 20022 message. | | Policy authorization | The policy wrapper verifies the sender or recipient VASP's signature and registered policy proof for the payment, phase, and payload commitment. | Initiation does not establish that the signing VASP serves the sender. Acceptance and rejection bind the signer to the recipient VASP commitment stored on the hold. | | Accuracy of party information | The responsible institution verifies and maintains the originator and beneficiary information. | Signatures and commitments cannot establish that a real-world identity claim is true. | 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. > [card] [IVMS evidence](https://docs.metalntwx.com/reference/compliance/ivms-evidence.md) > > Travel Rule fields, commitments, and verification boundaries. > [card] [Encrypted payment envelope](https://docs.metalntwx.com/reference/privacy/transfer-circuit.md#encrypted-payment-envelope) > > Note memo and institutional payload formats and encryption keys. > [card] [Programmable compliance](https://docs.metalntwx.com/learn/compliance/programmable-compliance.md) > > How each institution's policy governs payment execution. > [card] [Evidence and regulatory access](https://docs.metalntwx.com/learn/compliance/regulatory-access.md) > > Viewing capabilities, retained payment records, and audit disclosure. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.