# Way4 Mastercard Menu-Item Gap Checklist

**Purpose:** the narrative gap analysis (`way4-mc-interface-similarity-gap.md`) works
chapter-by-chapter through the *prose* of `way-4-mc-interface.txt`. This document works
**item-by-item through the menu-tree figures instead** (Fig. 3 and Fig. 12) — a different, more
exhaustive source, because Way4's menu trees show roughly three times as many named
items/screens as the prose ever explains. That gap between "what the tree shows" and "what the
text describes" is itself the first finding, below.

**Verdicts:** ✅ Built · 🟡 Partial · ❌ Gap · ⛔ N/A (not ours as an acquirer) · ❓ Undocumented
(the menu item exists in the figure; the supplied text never explains what it does — a different
Way4 manual, not supplied, presumably covers it. Marked this way rather than guessed at.)

---

## 0. First finding: how much of the menu tree the supplied text actually documents

Fig. 3 and Fig. 12 together show **26 named menu folders/items** at or near the top level of the
`MasterCard` module. Checking each against the manual text (`grep` across the full document):

| Top-level item (from Fig. 3 / Fig. 12) | Prose in supplied text? |
|---|---|
| MC. Daily Procedures | ✅ Yes — §3.1, §3.2 |
| MC. IRD Configuration | ❓ **No** — zero mentions |
| MC. File Management | ✅ Yes — §3.3 |
| MC. Fraud Management | ❓ **No** — zero mentions (SAFE is covered, but under a different chapter, §5, not under this menu folder) |
| MC. Merchant Management | 🟡 One mention — §7, and only for the Mastercard Assigned ID sub-flow |
| MC. Exception Lists | ❓ **No** — zero mentions |
| MC. Reports | ✅ Yes — §6 |
| MasterCard ALM | ❓ **No** — zero mentions |
| MasterCard Rewards System | ❓ **No** — zero mentions |
| MasterCard Fee Prediction | ❓ **No** — zero mentions |
| MasterCard CDF | ❓ **No** — zero mentions |
| MasterCard MCBS | ❓ **No** — zero mentions |
| MC Statistics Reports | ❓ **No** — zero mentions |
| MasterCards Statistics Reports OBSOLETE | ❓ **No** (marked obsolete by Way4 itself) |
| MDS | ❓ **No** — zero mentions |
| Message Channel Processing | ❓ **No** — zero mentions |
| OTP Cash | ❓ **No** — zero mentions |
| RF Reporting | ❓ **No** — zero mentions |
| Online Services | ❓ **No** — zero mentions |

**Reading this plainly: 13 of 19 top-level items (68%) have no explanation anywhere in the
document we were given.** `way-4-mc-interface.txt` is titled *"Mastercard Interchange
Interface Operation Manual"* and its own scope statement (p. 3) only promises to cover clearing
file exchange — it explicitly defers related topics to *other* manuals (*"SAFE Support"*,
*"Way4 Dispute Management"*, *"Interchange Routing"*, *"Currency Conversion"*, etc., all named
in its own front matter). ALM (Account Level Management), Rewards, Fee Prediction, CDF
(Compliance Data File?), MCBS, MDS, Message Channel Processing, OTP Cash, RF Reporting and
Online Services are each almost certainly whole separate Way4 products with their own manuals —
not gaps in *this* interface so much as modules outside this document's scope entirely. They are
listed below for completeness (§5) but not scored, because scoring an undocumented item is
guessing, not gap analysis.

**What this changes about the picture:** the narrative doc's "6 of X matched" framing was always
implicitly scoped to what the *text* discusses. This table shows that text is itself a minority
of what the *menu tree* shows. The real, useful comparison is menu-item-by-menu-item for the 6
items that do have prose (§1–§4 below) — everything else is a documented unknown, not a silent
one.

---

## 1. MC. Daily Procedures

**Updated 2026-08-26** — the Manage page's catalog card push closed most of this folder's
gaps; see §7 for the new roll-up. Statuses below now reflect what actually ships.

| Way4 menu item | What it does | Mercury | Where | Notes |
|---|---|---|---|---|
| MC. Inward Processing | Import incoming T112/T113 clearing files | ✅ Built | `Ipm.Ingestor`, `/admin/clearing/files` | |
| MC. Outward Processing | Prepare/export R111 outgoing clearing files | 🟡 Partial | `SettlementCore.MastercardOutboundPresentment`, `/admin/clearing/batches` | Real selection+encoding+trigger now exists; DE 2 uses `masked_pan` (PCI scope), so every file is forced to test mode (PDS 0122=T) — not submission-ready until a full-PAN/token source exists |
| MC. IntraProcessor Transactions Export | On-us transaction export (own cards, own devices) | ✅ Built | `ClearingCore.Context.list_intraprocessor_records/1`, `/admin/clearing/ipm-reports/intraprocessor` | DE 32 = DE 93 = one of our own ICAs; honestly empty if Mercury has no issuing BINs |
| SAFE Inward Processing | Import SAFE confirmation files | 🟡 Partial | `RiskCore.Safe.FileFormat` (sample format) + `/risk-management/safe-files` | Real decode+import now works; format is a clearly-labeled **sample**, not Mastercard's real SAFE layout (still doesn't exist in this project) |
| SAFE Outward Processing | Export SAFE fraud report files | 🟡 Partial | Same module, `build_outward_safe_file/3` | Real build+export now works; same sample-format caveat |
| Generate SAFE Negative Responses | Mandatory monthly nil-fraud filing | ✅ Built | `/risk-management/safe-cases?case_type=negative_report` | Real register screen now exists (list/filter/mark-reported); still no *file* automation (no spec) |
| MC. Load Bin Table and Handbooks → Load MPE Daily Files | Import T067 daily BIN table updates | 🟡 Partial | `SchemeCore.BinRange` + `mix load_scheme_bin_ranges` | Unchanged — data model + one-time import used; no *native*, ongoing T067 reader |
| MC. Load Bin Table and Handbooks → MC. Full Replacement → Load MPE Replacement Files | Import T068 full BIN table replacement | ❌ Gap | — | Unchanged — full-replacement semantics (vs. our fail-closed upsert) need explicit design |
| MC. Load Bin Table and Handbooks → Load MC Rates | Import T057/T058 currency rate files | ❌ Gap | — | Unchanged — not started |
| MC. Load Stop List → Load MC Stop List | Import T314/T316 Electronic Warning Bulletin (stop list) | ❌ Gap | — | Unchanged — not started. ⚠ Do not build this as `SchemeCore.Bulletin` — that table holds mandate notices (AN 1026-style), a name collision with Mastercard's own "bulletin" = stop list terminology |

---

## 2. MC. File Management

Way4's own menu tree (Fig. 3) lists fifteen items under this folder. The prose (§3.3) only
explains two of them (Received/Sent Files) in any detail, plus the Pending Files pair in
passing (§3.4.5). The rest are named in the tree with no further text — most are recoverable by
inference (they're clearly variants of the file lifecycle already described), a few are not.

| Way4 menu item | Inferred purpose | Mercury | Where | Notes |
|---|---|---|---|---|
| MC Received Files | List of imported physical files | ✅ Built | `/admin/clearing/files`, `/admin/clearing/batches` (filter: inbound) | |
| MC Sent Files | List of exported physical files | ✅ Built | `/admin/clearing/batches` (filter: outbound) | Now populated by a real trigger — see §1 Outward Processing |
| MC Incoming Pending Files | Files currently mid-import | ✅ Built | `/admin/clearing/batches?direction=inbound&state=pending` | `status in [received, processing]` was already a real, distinct lifecycle state — this was a missing filter, not missing data |
| MC Outgoing Pending Files | Files currently mid-export | ✅ Built | `/admin/clearing/batches?direction=outbound&state=pending` | `status == generated` (not yet submitted) |
| MC Rollbacked Incoming Files | Import-reversal audit trail | ✅ Built | `/admin/clearing/ipm-reports/rolled-back-incoming` | Audit-trail only, by design — a manual flag + reason, not an automatic unwind of exceptions/settlement postings |
| MC Rollbacked Outgoing Files | Export-reversal audit trail | ✅ Built | `/admin/clearing/ipm-reports/rolled-back-outgoing` | Same |
| MC Inward Clearing | Likely a clearing-specific (vs. all-message) view of received files | 🟡 Partial | `/admin/clearing/batches/:id` shows every message including non-clearing ones | Unchanged — we don't split by message class in the UI; `MessageCatalog.category/2` makes it queryable if needed |
| MC Outward Clearing | Same, outbound | 🟡 Partial | Same caveat | Unchanged |
| MC Inward Documents | Per-message decoded view (Way4's "Original Docs") | ✅ Built | `/admin/clearing/batches/:id` | |
| MC Outward Documents | Same, outbound | ✅ Built | Same screen, filter by direction | |
| MC Rejects | Files/messages Mastercard rejected on submission | ✅ Built | `/admin/clearing/file-rejects/list` | File Reject (1644/699) was already decoded onto `IpmRecord` by the ingestor (administrative-class messages are stored, not skipped) — only the registry screen was missing |
| MC Message To Member | Send/view Text Message/1644 (MTI 1644, function 693) administrative messages | 🟡 Partial | `/admin/clearing/member-messages` | View built (same "already decoded" discovery as Rejects); sending a standalone envelope is not — `OutboundSubmitter` only transports a full presentment file |
| MC SAFE Received Files | Inbound SAFE file list | 🟡 Partial | `/risk-management/safe-files?direction=inbound` | Real registry now exists; sample file format (see §1) |
| MC SAFE Sent Files | Outbound SAFE file list | 🟡 Partial | `/risk-management/safe-files?direction=outbound` | Same |
| MC Outward Rejected | Outbound files Mastercard rejected | ✅ Built | `/admin/clearing/file-rejects/list` | Same feed as MC Rejects — Mercury has no issuing side in this dataset, so every File Reject message is inherently about an outward submission |

**Net for this folder, updated 2026-08-26: 10 of 15 built, 5 partial, 0 gaps.** The bulk of this
folder's original 9 gaps turned out to be **already-decoded data with no screen over it** — File
Reject and Text Message are administrative-class IPM messages the ingestor was already storing;
the "gap" was the missing UI, not missing ingestion.

---

## 3. MC. Reports

The one folder where the menu tree (Fig. 12) and the prose (§6) actually agree closely — every
item in the tree has a corresponding paragraph in the text.

| Way4 menu item | Mercury | Where | Notes |
|---|---|---|---|
| MC. Details | ❓ Undocumented | — | Named in the tree, no prose — still nothing to build against |
| Collect Doc Statistics | ❓ Undocumented | — | Same |
| MC Submission Report (briefly) | ✅ Built | `/admin/clearing/ipm-reports/submission` | Outbound batches confirmed `status == submitted`, distinct from Sent Files (which shows every outcome) |
| MC Acknowledgement Report (briefly) | ❌ Gap | — | Unchanged — no Mastercard ACK-file ingestion exists (a different thing from a clearing message) |
| MC Notification Report (briefly) | ✅ Built | `/admin/clearing/settlement-position/notifications` | **Finding:** PDS 0159 (Settlement Service ID/dates/cycle) was already decoded onto every `IpmRecord` that carries it by `Ipm.Ingestor` — this was never a missing codec, only a missing screen |
| MC Settlement Report (briefly) | ✅ Built | `/admin/clearing/settlement-position/settlement` | Same underlying data, grouped by Settlement Service ID + date |
| MC Settlement Results (briefly) | ✅ Built | `/admin/clearing/settlement-position/results` | Same data, grouped by settlement cycle |
| MC Conversion Report (briefly) | ❌ Gap | — | Unchanged — no currency-conversion tracking exists to report on |
| IPM Incoming Files Summary Report | ✅ Built | `/admin/clearing/ipm-reports/incoming-summary` | Real per-date batch/record/amount aggregation, not a re-labeled batch list |
| IPM Outgoing Files Summary Report | ✅ Built | `/admin/clearing/ipm-reports/outgoing-summary` | Same query, outbound — meaningful now that Outward Processing (§1) actually submits |
| IPM Inward Monetary Transactions Report | ✅ Built | `/admin/clearing/ipm-reports/inward-monetary` | Grouped by message type + currency, real query |
| IPM Outward Monetary Transactions Report | ✅ Built | `/admin/clearing/ipm-reports/outward-monetary` | Same, outbound |
| ATM Location | ⛔ N/A | — | Unchanged — no ATM estate |
| MC Reject Report | ✅ Built | `/admin/clearing/file-rejects/report` | Same "already decoded" finding as §2's MC Rejects, grouped by reason code |
| MC Dispute Statistics | ✅ Built | `/admin/chargebacks/dispute-analytics?scheme=mastercard` | Now scheme-filterable — `DisputeCore.Analytics` already had `scheme_name`, just not threaded through this page's functions |

---

## 4. MC. Merchant Management — the one item with real detail (Ch. 7)

| Way4 capability | Mercury | Where | Notes |
|---|---|---|---|
| MasterCard Assigned ID — merchant contract parameter | ✅ Built | `/admin/merchants/mastercard-assigned-ids`, `SettlementCore.ClearingBridge.list_merchant_assigned_ids/0` | A **live join** (`IpmRecord` → `core_transactions.merchant_mid`), deliberately not a stored field — `SettlementCore.Mms.Merchant` is a read-only mirror of the external MMS database this app never writes to |
| MasterCard Assigned ID at device-child-contract level | ❌ Gap | — | Unchanged, deliberately: confirmed via code search that no device-level identity model exists anywhere (`TidMaster` is one row per *merchant* with `tid` as an array, not one row per device) — building one now would preempt the merchant/MMS data-model decision already deferred elsewhere in this project |

Everything else under this folder in the tree (merchant contracts generally, acquiring
configuration) has no further Way4 prose to compare against.

---

## 5. Chapter 8 — MoneySend, broken into its five real subsections

The narrative doc bundled this as one row. Here it is at the granularity Way4's own chapter
structure uses, since that's closer to what "not matched yet" should mean for a feature this
specific.

| Way4 subsection | What it configures | Mercury | Notes |
|---|---|---|---|
| 8.1 SIC Groups | A "MasterCard MoneySend" SIC group with the scheme's own SIC code list | ✅ Built | `/admin/clearing/moneysend/sic-groups` — real reference-data CRUD, owned by Clearing & Settlement (not Payments, per correction) |
| 8.2 Transaction Types | "Notif Prs Credit Item" transaction type + message type `124020028A` | ✅ Built | `/admin/clearing/moneysend/transaction-types` |
| 8.3 Configuring Services | Card contract Target services, credit-hold semantics (`DOC_MODE=SMS`, `PENDING=Y`) | ⛔ N/A | **Scope confirmed 2026-08-26:** switch-side (`mercury_device_middlelayer`), same boundary already established for payments routing — not built here |
| 8.4 Other Parameters | `MC_FAST_FUNDS` global parameter, `USE_PAYMENT_TRANSACTION` pipe check | ⛔ N/A | Same confirmed boundary |
| 8.5 Transaction Processing | Auth→financial conversion, clearing-doc-to-original-doc matching for MoneySend | ⛔ N/A | Same confirmed boundary — disbursement is the switch's job |

**Verdict, updated 2026-08-26:** scope question resolved, not just suspected — MoneySend is
reference-data-only in TMS. SIC Groups and Transaction Types (the two genuinely
reference-shaped subsections) are built; the three that describe switch-side disbursement logic
are marked N/A rather than left as open gaps.

---

## 6. Undocumented sibling modules (❓ — not scored)

Named in Fig. 12's menu tree, zero prose anywhere in the supplied text. Listed so nothing is
silently dropped from the comparison, not scored, because there is nothing to score against.

| Item | Best guess at real-world purpose (unconfirmed) |
|---|---|
| MC. IRD Configuration | Interchange Rate Designator setup — plausibly where PDS 0158 subfield 4 values get assigned per business arrangement |
| MC. Fraud Management | Likely SAFE-adjacent, possibly the operational home for the same fraud data covered narratively under Ch. 5 |
| MC. Exception Lists | Possibly a stop-list / negative-file management screen, separate from the T314/T316 import itself |
| MasterCard ALM | Account Level Management — a distinct Mastercard program (per-account interchange tiering) |
| MasterCard Rewards System | Loyalty/rewards program administration |
| MasterCard Fee Prediction | Interchange fee estimation tooling |
| MasterCard CDF | Unclear expansion — possibly "Compliance Data File" |
| MasterCard MCBS | Unclear expansion |
| MC Statistics Reports | A second, separate reports folder from MC.Reports — scope unclear |
| MasterCards Statistics Reports OBSOLETE | Marked obsolete by Way4 itself — safe to ignore |
| MDS | Mastercard Debit Switch, or Merchant/Member Data Service — unclear which |
| Message Channel Processing | Likely low-level transport/channel configuration, adjacent to what `Ipm.SftpClient`/`Ipm.Scheduler` now cover for Mercury |
| OTP Cash | Unclear — possibly a cash-related OTP/authentication product, may not even be Mastercard-specific |
| RF Reporting | Unclear expansion — possibly "Risk & Fraud Reporting" |
| Online Services | Likely the real-time authorization side Way4's own scope statement excludes from this manual |

If any of these turn out to matter, the next step is the same one that closed the IPM and GCMS
gaps earlier in this project: get the real Way4 manual that documents that specific module,
rather than build against a guess.

---

## 7. Summary roll-up

**Updated 2026-08-26**, after the Manage page's coverage catalog (built to surface exactly this
gap) drove a build push against it. Kept as a distinct dated snapshot rather than silently
overwritten — see the note at the end of this section for how the two waves differ.

| Section | ✅ Built | 🟡 Partial | ❌ Gap | ⛔ N/A | ❓ Undocumented |
|---|---|---|---|---|---|
| §1 Daily Procedures (10 items) | 3 | 4 | 3 | 0 | 0 |
| §2 File Management (15 items) | 10 | 5 | 0 | 0 | 0 |
| §3 Reports (15 items) | 10 | 0 | 2 | 1 | 2 |
| §4 Merchant Management (2 items) | 1 | 0 | 1 | 0 | 0 |
| §5 MoneySend (5 subsections) | 2 | 0 | 0 | 3 | 0 |
| §6 Sibling modules (15 items) | 0 | 0 | 0 | 0 | 15 |
| **Total (62 items)** | **26** | **9** | **6** | **4** | **17** |
| **Total, scored items only (45)** | **26** | **9** | **6** | **4** | **—** |

**Reading it straight:** of the 45 menu items this project has enough documentation to actually
score, 26 are now built, 9 partial, 6 are real gaps, and 4 are confirmed out of scope — up from
5/9/30/1 at the previous snapshot. Two things drove most of the movement, worth naming plainly
because they say something about how "gap" got measured, not just how much got built:

1. **Several "gaps" were already-decoded data with no screen over it.** File Reject (1644/699),
   Text Message (1644/693), and Settlement Position Detail (1644/688, PDS 0159) were all already
   being stored onto `IpmRecord` by `Ipm.Ingestor` — administrative/reconciliation messages are
   persisted, not skipped (see its own moduledoc). Six of §2/§3's gaps closed by writing a report
   screen against data that was already there, not by building new ingestion.
2. **Two scope questions got resolved instead of assumed.** MoneySend's disbursement
   subsections (8.3–8.5) moved from ❌ Gap to ⛔ N/A on an explicit decision, not a guess — same
   boundary already established for payments routing (switch-owned, `mercury_device_middlelayer`).
   Device-Child Contract ID stays a gap on an equally explicit decision: no device-level identity
   model exists anywhere in this codebase, and inventing one would preempt a merchant/MMS
   data-model decision already deferred elsewhere.

What's still genuinely open, honestly: MPE Replacement/MC Rates/MC Stop List file loaders,
Acknowledgement/Conversion Reports (no Mastercard ACK-file or currency-conversion data exists to
report on), and Device-Child Contract ID. Outward Processing and the whole SAFE file exchange are
real but explicitly incomplete — Outward Processing's DE 2 uses a masked PAN (this app's PCI
scope never stores the full PAN) so every file it builds is forced to test mode; SAFE's file
format is a clearly-labeled sample, not Mastercard's real layout, which still doesn't exist in
this project. Use the narrative doc (`way4-mc-interface-similarity-gap.md`) for *why* and
*what's architecturally significant*; use this one for *how much of the literal menu tree is
actually there*.