> ## 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. # Evidence and Regulatory Access > How Metal supports payment audits through recorded outcomes, shielded viewing, and verifiable disclosures Payment service providers (PSPs) need to be able to explain the payments they process and provide supporting evidence when auditors or regulators request it. Metal supports this through recorded payment outcomes, delegated viewing access for shielded payments, and verification of disclosed payment information. A PSP combines these capabilities with its retained customer records, payment instructions, and decision history. Together, they support a review of what happened, who was involved, and which checks supported the payment. ## MIP20: public transfers When a payment is queried, the PSP uses its payment reference to retrieve both the onchain transactions and the records supporting its decision. The public transfer history establishes what happened to the funds, while the PSP's retained evidence explains which checks were performed and why the payment was permitted. ### Onchain payment and policy records MIP20 publishes the transferred token, sender and credited addresses, and amount, so a reviewer can inspect the movement of funds directly. The PSP identifies the transfer in the finalized transaction history using the chain ID, token address, transaction hash, and transfer event's log index. For a quarantined payment, the transfer names the escrow as the credited address, and the `Quarantined` event identifies the intended recipient. A send policy contract can enforce the PSP's outgoing rules before calling MIP20 to transfer funds. For example, a screening service can issue a signed decision for a specific payment. When the PSP's policy requires that approval, the contract verifies who signed it and that it applies to the transfer being executed. If the required evidence is missing or invalid, the call reverts. When the signed decision is submitted as public calldata, a reviewer can inspect the approval evaluated by the send policy contract. By examining that decision alongside the payment rules in force at execution, the reviewer can establish which conditions the payment satisfied. ### Evidence retained by the PSP The PSP retains the payment instruction, screening reports, relevant customer and Travel Rule records, and any decisions from manual review under the same payment reference. These records accumulate during processing, including attempts that never reach the chain, and explain the information and checks behind the PSP's decision. A payment may require several submission attempts, so the PSP records each attempt under the original payment reference. The reviewer can then examine those attempts together and check the finalized transaction results to establish which transfers executed. | Records held in the PSP's systems | Role in the audit | | - | - | | Payment instruction, payment references, and onchain references | Identify the requested payment, its submission attempts, and the recorded outcome. | | Full quarantine receipts and claim references, where present | Track funds in escrow and establish the destination of a later recovery. | | Customer records, exchanged messages, and Travel Rule records where applicable | Identify the parties and establish which information the PSP held or received. | | Policy version, screening results, supporting evidence, and decision history | Explain the checks and decisions, including rejection, failed delivery, retries, and expiry. | | Signed decisions, private records used by the policy, and any additional values needed to verify commitments, such as salts | Allow later disclosure and verification against the transfer. | | Original records and linked corrections | Show what changed while preserving the information used for earlier decisions. | ### Access for auditors and regulators When an auditor or regulator requests a review, the PSP supplies the retained records alongside the transaction references. For sanctions screening, the supporting records explain who was screened, which screening data was used, when the check occurred, and how any matches were resolved. This lets the reviewer assess the basis for the PSP's payment decision. Where a policy contract verifies a commitment to a private record, the PSP supplies the record and any additional data needed to verify that commitment, such as the salt used to create it. A signature authenticates the signer, while a commitment lets the reviewer check that the disclosed data matches the committed record. The supporting records provide the basis for the PSP's identity claims and compliance decisions. ## MIP410: shielded payments A shielded MIP410 payment exposes its hold and resolution while keeping its asset, amount, and shielded sender and recipient details private. A reviewer obtains the private details through viewing access or a disclosure from an institution holding the records. ### Onchain payment and policy records The PSP records the chain ID, pool contract address, hold ID, and initiation and resolution transaction hashes for each payment. With these references, a reviewer can follow the hold and establish whether it is pending, accepted, rejected, or reclaimed. A successful initiation transaction reserves funds, but the payment settles only when the recipient virtual asset service provider (VASP) accepts it. If the recipient VASP rejects the payment, the reserved notes become available again without being spent. If the hold expires instead, the notes remain locked until a reclaim transaction releases them. The hold also stores a **payload commitment**, a cryptographic value binding the payment to its identifiers and any included Travel Rule record. The sender VASP supplies the policy-wrapper proof at initiation, and the recipient VASP supplies it at acceptance or rejection. The proof establishes authorization and approval under the registered policy for that phase. ### Evidence retained by the PSP As with MIP20, the PSP retains the instructions, customer records, checks, and decisions for each payment, including failed attempts and subsequent corrections. For shielded payments, it also retains the private payment data, signatures, relevant records from the pool's institution registry, and the salts and other values used to compute the commitments. These allow a later disclosure to be checked against the onchain commitments. MIP410's **institutional payload** carries the payment identifiers and any Travel Rule record, encrypted for the recipient VASP. The sender VASP signs the payload commitment with its messaging secret key, and the signature forms part of the retained evidence. Customer identity records and the reasons for policy decisions also come from the institutions holding them. The PSP links additional material, such as screening reports and notes from manual review, through its own records. Those documents are not automatically covered by the payload commitment. As with MIP20, the PSP manages storage, access, retention, and export under its applicable rules. MIP410 does not check that these records were retained or require their delivery to an auditor before settlement. ### Access for auditors and regulators MIP410 provides two levels of access: disclosure of selected payment records, and wallet viewing through delegated keys when a broader review is needed. #### Selected payment disclosure When an auditor or regulator requests information about specific payments, the PSP discloses the relevant records. For records covered by a commitment, it also supplies the salts and any other values the reviewer needs to recompute that commitment. The reviewer can therefore examine the requested payments without receiving the wallet's viewing keys. The PSP controls disclosure of the records it holds. The VASP can disclose payment identifiers and Travel Rule records from the decrypted institutional payload while keeping its messaging secret key private. That key also signs payment requests and policy authorizations. MIP410 gives the reviewer a way to check that disclosed payment information matches what was committed when the payment was initiated. Recomputing a commitment requires the disclosed values, the relevant salts, and any other inputs used in its calculation. Matching the onchain commitment shows that the values match the committed data. A changed committed value fails that check. The diagram shows how a reviewer matches a PSP's retained records to a MIP410 payment. The arrows represent evidence checks and record links. Private records remain offchain. ![A reviewer links PSP records to the hold, recomputes its payload commitment from private inputs, and follows the same hold ID to the recorded outcome.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/compliance/payment-evidence.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=63d55ad094643c32be4ca5efee9ec1e7) | Evidence available to a reviewer | What it establishes | | - | - | | Finalized transaction and events | The hold reached the recorded outcome. | | Private note and payload data, with the salts and other values needed to recompute their commitments | The disclosed values reproduce the relevant onchain commitments. | | Sender VASP's payload signature | The payload commitment was signed by the sender VASP's messaging key. The relevant state of the pool's institution registry identifies its messaging public key. | | MIP410 policy-wrapper proof verified during execution | The VASP authorized that payment phase and its registered policy permitted it. | The PSP's supporting records explain why an offchain decision was made and provide the basis for its customer identity claims. A signature authenticates the signer, while a commitment lets the reviewer check that the disclosed data matches the committed record. These checks do not establish the real-world accuracy of the identity data. The [IVMS evidence reference](https://docs.metalntwx.com/reference/compliance/ivms-evidence.md) defines the fields covered by the MIP410 payload commitment. #### Wallet viewing If the review requires broader access to a wallet's activity, the wallet or custodian can share its viewing capability: the incoming viewing key (`ivk`) and nullifier key (`nk`), together with access to the required payment data. These keys grant viewing access without spending authority, so payment authorization remains with the holder of the spending key. The [incoming viewing key](https://docs.metalntwx.com/learn/mip410/key-and-addresses.md) decrypts note memos addressed to the wallet. These reveal received notes, including their asset and amount. The nullifier key also lets a reviewer identify when known notes are spent, using the corresponding note data and positions in the commitment tree. The reviewer needs access to that data and the encrypted memos as well as the keys. The incoming viewing key covers all diversified addresses derived from it. The viewing capability has no built-in expiry or onchain revocation. A copied key can continue to decrypt available ciphertext within that scope. Independent incoming viewing keys define separate scopes. However, this access does not reveal every outgoing payment's amount and destination, so the PSP's retained outgoing payment records supply those details. Wallet viewing also does not decrypt the institutional payload, which the VASP discloses separately when the review requires it. The MIP410 authority is the pool administrator and manages its registries and controls. That role does not automatically grant access to private payment data. Wallet viewing requires the relevant wallet's viewing capability and payment data to be supplied separately. > [card] [Payment messaging](https://docs.metalntwx.com/learn/compliance/messaging.md) > > Payment instructions, Travel Rule exchange, and message authentication. > [card] [Keys and addresses](https://docs.metalntwx.com/learn/mip410/key-and-addresses.md) > > Viewing capabilities and the scope of delegated access. > [card] [IVMS evidence](https://docs.metalntwx.com/reference/compliance/ivms-evidence.md) > > Committed fields and verification of disclosed payment information. > [card] [Programmable compliance](https://docs.metalntwx.com/learn/compliance/programmable-compliance.md) > > How institutional policies govern payment execution. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.