MTD-TEC-01 · Payment Platforms Design Note (v2.1)
The registry entry for this document — where it came from, what it says, and which
assessments its passages are filed to.
Active
Internal
v1
mtd-tec-01-payment-platforms-design-note.md
4542 bytes · owner Head of Payments Operationsas at 2025-05-22 (approval date)
Identity, integrity & provenance
b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393Allocated to assessments
Where this document's content was filed at triage — 3 sections. A section can be allocated to more than one assessment. Change it with Triage and allocate, in the actions at the top of this page.
3.1 Each customer holds a single account record. The record is mastered in Garnet; customers using the digital-asset service are mirrored to Osprey, and changes propagate on the overnight synchronisation. The account record is the source for customer-facing display, statements, and operational processing on both platforms.
3.2 The principal fields of the account record, and where each is maintained:
Field Maintained by Notes Verified legal name Customer due diligence process Established at onboarding under the Customer Due Diligence Standard; updated on re-verification Registered address Customer due diligence process As evidenced at verification Date of birth / registration number Customer due diligence process Natural and legal persons respectively Account identifiers System-generated IBAN (Garnet); wallet and account references (Osprey) Display name Customer, in-app Free-text account label; shown in the app and on statements Contact details and notification preferences Customer, in-app Email address and notification settings 3.3 Fields maintained by the customer due diligence process are updated only through that process. Fields maintained by the customer may be changed in the app at any time; changes take effect immediately in Garnet and reach Osprey on the overnight synchronisation.
Describes the account record data model of Mittenda Limited's own payment (Garnet) and digital-asset (Osprey) platforms, owned by its Head of Payments Operations; this is the source of payer/originator data and identifiers the firm operates as PSP and CASP.
6.1 The platforms run the following scheduled reconciliations. Breaks are investigated by the operations team that owns the reconciliation and escalated under the incident-handling provisions of the operations procedures.
6.2 The reconciliation schedule:
Reconciliation Frequency Platform Correspondent (nostro) account reconciliation Daily Garnet Scheme settlement reconciliation Daily Garnet Internal ledger to platform position Daily Garnet On-chain wallet balance reconciliation Daily Osprey Batch header totals check Per batch Garnet Suspense account review Weekly Garnet Fee ledger reconciliation Monthly Garnet and Osprey 6.3 Reconciliation results and break investigations are retained under the Record Retention Policy.
Reconciliations and integrity checks run on Mittenda Limited's own platforms and performed by its operations teams; operational controls the firm itself owns.
7.1 External and internal data feeds consumed by the platforms:
Feed Frequency Consumer Sanctions list updates Daily Screening on both platforms Scheme reference data (routing directories) Weekly Garnet Foreign exchange reference rates Daily Garnet Core ledger synchronisation Continuous Garnet 7.2 Feed failures raise platform alerts and are handled under the incident-handling provisions of the operations procedures.
Data feeds consumed by Mittenda Limited's own Garnet and Osprey platforms, including the sanctions list feed its screening uses; operated and owned by the firm.
Not allocated
Text no triage section covers — 7 passages. Often this is the title, document-control metadata or sign-off; if any of it belongs to an assessment, file it with Triage and allocate, in the actions at the top of this page.
# Mittenda Limited · Payment Platforms Design Note (v
) · 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: the platform teams' description of the > payment platforms as built. It is deliberately outside the diagnostic's corpus (stage one > reads the governing tier); it enters at stage two, where the assessed risks pull in the > operational facts. It covers both platforms: Garnet (payments) and Osprey (digital-asset). **Document control:**
. | Version | Date | Change | |---|---|---| |
| May 2025 | On-chain wallet balance reconciliation added to the schedule | | 2.0 | April 2025 | Osprey platform sections added | | 1.6 | November 2024 | Data feed inventory refreshed | *[Earlier versions omitted]* **Contents** 1. Purpose and scope 2. Platform architecture overview 3. **Account data model** 4. Payment initiation interfaces 5. Message assembly and scheme interfaces 6. **Reconciliations and integrity checks** 7. **Data feeds and integrations** 8. Access control and segregation of duties 9. Environments and change management Appendix A: Interface inventory Appendix B: Retention and archival configuration *Sections in bold are excerpted below.* *[Sections 1 to 2 omitted]* ## 3. Account data model
*[Sections 4 to 5 omitted]* ## 6. Reconciliations and integrity checks
## 7. Data feeds and integrations
*[Sections 8 onward, Appendix A and Appendix B omitted]*
Document text
Mittenda Limited · Payment Platforms Design Note (v2.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: the platform teams' description of the payment platforms as built. It is deliberately outside the diagnostic's corpus (stage one reads the governing tier); it enters at stage two, where the assessed risks pull in the operational facts. It covers both platforms: Garnet (payments) and Osprey (digital-asset).
Document control: MTD-TEC-01 · owner: Head of Payments Operations · approved: Chief Operating Officer, 22 May 2025 · classification: Internal · uncontrolled when printed · next review due: May 2026.
| Version | Date | Change |
|---|---|---|
| 2.1 | May 2025 | On-chain wallet balance reconciliation added to the schedule |
| 2.0 | April 2025 | Osprey platform sections added |
| 1.6 | November 2024 | Data feed inventory refreshed |
[Earlier versions omitted]
Contents
- Purpose and scope
- Platform architecture overview
- Account data model
- Payment initiation interfaces
- Message assembly and scheme interfaces
- Reconciliations and integrity checks
- Data feeds and integrations
- Access control and segregation of duties
- Environments and change management
Appendix A: Interface inventory
Appendix B: Retention and archival configuration
Sections in bold are excerpted below.
[Sections 1 to 2 omitted]
3. Account data model
3.1 Each customer holds a single account record. The record is mastered in Garnet; customers using the digital-asset service are mirrored to Osprey, and changes propagate on the overnight synchronisation. The account record is the source for customer-facing display, statements, and operational processing on both platforms.
3.2 The principal fields of the account record, and where each is maintained:
| Field | Maintained by | Notes |
|---|---|---|
| Verified legal name | Customer due diligence process | Established at onboarding under the Customer Due Diligence Standard; updated on re-verification |
| Registered address | Customer due diligence process | As evidenced at verification |
| Date of birth / registration number | Customer due diligence process | Natural and legal persons respectively |
| Account identifiers | System-generated | IBAN (Garnet); wallet and account references (Osprey) |
| Display name | Customer, in-app | Free-text account label; shown in the app and on statements |
| Contact details and notification preferences | Customer, in-app | Email address and notification settings |
3.3 Fields maintained by the customer due diligence process are updated only through that process. Fields maintained by the customer may be changed in the app at any time; changes take effect immediately in Garnet and reach Osprey on the overnight synchronisation.
[Sections 4 to 5 omitted]
6. Reconciliations and integrity checks
6.1 The platforms run the following scheduled reconciliations. Breaks are investigated by the operations team that owns the reconciliation and escalated under the incident-handling provisions of the operations procedures.
6.2 The reconciliation schedule:
| Reconciliation | Frequency | Platform |
|---|---|---|
| Correspondent (nostro) account reconciliation | Daily | Garnet |
| Scheme settlement reconciliation | Daily | Garnet |
| Internal ledger to platform position | Daily | Garnet |
| On-chain wallet balance reconciliation | Daily | Osprey |
| Batch header totals check | Per batch | Garnet |
| Suspense account review | Weekly | Garnet |
| Fee ledger reconciliation | Monthly | Garnet and Osprey |
6.3 Reconciliation results and break investigations are retained under the Record Retention Policy.
7. Data feeds and integrations
7.1 External and internal data feeds consumed by the platforms:
| Feed | Frequency | Consumer |
|---|---|---|
| Sanctions list updates | Daily | Screening on both platforms |
| Scheme reference data (routing directories) | Weekly | Garnet |
| Foreign exchange reference rates | Daily | Garnet |
| Core ledger synchronisation | Continuous | Garnet |
7.2 Feed failures raise platform alerts and are handled under the incident-handling provisions of the operations procedures.
[Sections 8 onward, Appendix A and Appendix B omitted]
What it evidences
| Cited by | Suggestion | Version | When |
|---|---|---|---|
| Mittenda Limited | Risk examination Documented, not evidenced — Originator information verification not validly performed before transfer sg-0392 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 21:50 |
| Mittenda Limited | Coverage Not evidenced — Verification record identity match check sg-0388 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 20:13 |
| Mittenda Limited | Coverage Not evidenced — Trading-name fallback gate tied to technical-limitation basis sg-0389 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 20:13 |
| Mittenda Limited | Coverage Not evidenced — On-demand retrieval index for originator KYC information sg-0386 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 20:13 |
| Mittenda Limited | Coverage Not evidenced — Legal-person beneficiary registered-name dispatch verification sg-0383 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 20:13 |
| Mittenda Limited | Coverage Not evidenced — Accompaniment incident and metrics monitoring sg-0379 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 20:13 |
| Mittenda Limited | Coverage Not evidenced — Monitoring and refresh of messaging-system rulebook changes sg-0373 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 20:13 |
| Mittenda Limited | Coverage Not evidenced — Post-dispatch exemption classification audit sg-0370 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 20:13 |
| Mittenda Limited | Coverage Not evidenced — Post-dispatch originator-information sampling review sg-0366 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 20:13 |
| Mittenda Limited | Coverage Not evidenced — Post-dispatch sampling review of verification sg-0361 | current — v1sha256 b432b2fabf3dd0a0ab47548381bdb2ca73e66948b12226436e46dcaab41fd393 |
2026-10-04 20:13 |
Assistant findings
46 grounded in this documentWhat the assistant surfaced from this document — accept or reject them on the findings and coverage page.
| Finding | Value | Confidence | Status |
|---|---|---|---|
| Originator's name sg-0018 | Not evidenced | Medium | Accepted |
| Originator name as accompanying information sg-0023 | Not evidenced | Medium | Accepted |
| Verify accuracy of originator information before transferring sg-0037 | Not evidenced | Medium | Accepted |
| Verification of originator information against a reliable source before transfer sg-0045 | Not evidenced | Medium | Accepted |
| Originator name not accompanying transfer sg-0051 | marks risk live | Medium | Accepted |
| Originator name not accompanying transfer sg-0055 | Confirm in the design note that outgoing transfers on Garnet and Osprey take the verified legal name, never the display name. Make sure an Osprey transfer cannot leave on a name the overnight synchronisation has not yet updated. | Medium | Accepted |
| Head of Payments Operations sg-0061 | Head of Payments Operations | High | Accepted |
| Chief Operating Officer sg-0063 | Chief Operating Officer (person) | High | Accepted |
| Originator address, official document or birth details sg-0127 | Partial | Medium | Accepted |
| Originator LEI or equivalent official identifier where available sg-0136 | Not evidenced | Medium | Accepted |
Audit timeline
Every event on this document (62)
| When (UTC) | Actor | What | Change |
|---|---|---|---|
| 2026-10-06 13:38:12 | Demo User | Document viewed | "MTD-TEC-01 · Payment Platforms Design Note (v2.1)" opened on the register detail. |
| 2026-10-06 13:38:12 | Demo User | Document content_accessed | Content read by a Restricted clearance (document Internal). |
| 2026-10-06 10:11:03 | Demo User | Document viewed | "MTD-TEC-01 · Payment Platforms Design Note (v2.1)" opened on the register detail. |
| 2026-10-06 10:11:02 | Demo User | Document content_accessed | Content read by a Restricted clearance (document Internal). |
| 2026-10-06 10:05:35 | Demo User | Document viewed | "MTD-TEC-01 · Payment Platforms Design Note (v2.1)" opened on the register detail. |
| 2026-10-06 10:05:35 | Demo User | Document content_accessed | Content read by a Restricted clearance (document Internal). |
| 2026-10-06 08:53:44 | Demo User | Document viewed | "MTD-TEC-01 · Payment Platforms Design Note (v2.1)" opened on the register detail. |
| 2026-10-06 08:53:43 | Demo User | Document content_accessed | Content read by a Restricted clearance (document Internal). |
| 2026-10-05 10:22:29 | Demo User | Document viewed | "MTD-TEC-01 · Payment Platforms Design Note (v2.1)" opened on the register detail. |
| 2026-10-05 10:22:29 | Demo User | Document content_accessed | Content read by a Restricted clearance (document Internal). |
| 2026-10-04 21:50:24 | Demo User | Document cited | Cited by an accepted suggestion. |
| 2026-10-04 20:13:07 | Demo User | Document cited | Cited by an accepted suggestion. |
| 2026-10-04 20:13:07 | Demo User | Document cited | Cited by an accepted suggestion. |
| 2026-10-04 20:13:07 | Demo User | Document cited | Cited by an accepted suggestion. |
| 2026-10-04 20:13:07 | Demo User | Document cited | Cited by an accepted suggestion. |
15 of 62 shown
| |||