MTD-PRC-01 · Payments Operations Procedure (v3.1)

Mittenda Limited · Payments Operations Procedure (v3.1) · specimen excerpt

Synthetic specimen. Mittenda Limited is a fictional firm. This document is invented, derived from scenarios seen in practice, and contains deliberate deficiencies for demonstration. It is not a template and must not be adopted.

Tier note. This is an operational-tier document. It is deliberately outside the diagnostic's corpus (stage one reads the governing tier); it enters at stage two, where the question is whether the procedures implement what the governing tier requires. It covers the funds rail; its crypto-asset counterpart is the Crypto-Asset Transfer Operations Procedure.

Document control: MTD-PRC-01 · owner: Head of Payments Operations · approved: Chief Operating Officer, 6 October 2025 · classification: Internal · uncontrolled when printed · next review due: October 2026.

[Earlier versions omitted]

Contents

1. Purpose and scope
2. Initiation channels
3. Authorisation and consent
4. Funds and limit checks
5. Fees and foreign exchange
6. Scheme selection and routing
7. Cut-offs and value dating
8. Recalls and returns
9. Rejects and repairs
10. Incident handling
11. Outbound message handling
12. Inbound message handling
13. Settlement and accounting

Appendix A: Scheme message formats

Sections in bold are excerpted below.

[Sections 1 to 10 omitted]

11. Outbound message handling

[§11.1 to §11.2 omitted]

11.3 Raise the outbound message in Garnet at the point of initiation, in the format the selected scheme requires: SEPA credit transfer, SEPA instant credit transfer, or cross-border payment via the correspondent network.

11.4 Populate the originator name, address and account fields from the customer account record in Garnet. Do not key them by hand.

11.5 Screen the assembled message against the applicable sanctions lists before release. Where a potential match is raised, hold the message; the screening analyst handles the match under the Sanctions Screening Standard §5.

11.6 Where an account has more than one holder, populate the message with the primary account holder by default.

11.7 Route messages failing scheme schema validation to the repairs queue under §9. A payments repairs analyst corrects and resubmits them; resubmitted messages re-enter validation and screening before release. Roll items repaired after the scheme cut-off to the next settlement window.

11.8 Release manually repaired messages under four-eyes control: the analyst who repaired the message does not release it, and release falls to a second payments officer.

[Sections 12 onward and Appendix A omitted]