Read these four questions in the order MAS actually asks them, not the order that feels most comfortable to answer, and Solstice Pay's honest gaps become the useful part of this page, not the embarrassing part. Question one, the dismissed-alert audit trail, is the one every institution I have inspected assumes it has covered because escalated alerts are well documented. Dismissed alerts are the blind spot, because nobody reviews a decision not to act with the same rigour as a decision to act. Free-text reason codes are a genuinely common finding, not a hypothetical one, and the fact that Solstice Pay already retains five years of dismissed-alert logs means the fix here is a data-quality project, not a build-from-scratch one. I would tell a room this is a good problem to have relative to where most institutions start.

Question two is where I would push back hardest in a real engagement, and I want to be specific about why. "Reviewed monthly" is not the same claim as "measured against a baseline," and MAS inspectors know the difference, because a monthly review without a fixed reference point can show a stable or improving trend purely from transaction-volume growth diluting the alert rate, with the model's actual precision unchanged or worse. An eighteen-month-old threshold set with no re-baseline is exactly the scenario an inspector is trained to probe, and Solstice Pay's honest "not yet" here is the right answer to give rather than a fabricated baseline retrofitted to look complete.

Question three, the override authority and its 15 percent trigger threshold, is doing real work that I'd defend as written. A named override authority with a mandatory review trigger is precisely the control MAS wants to see evidence of: not that the model is never wrong, but that a human is accountable when it is, and that persistent disagreement between model and analyst is a signal the institution acts on rather than absorbs silently.

Question four is the one I'd spend the most time on with Solstice Pay's team directly, because a red-team exercise that actually finds a blind spot, the three-or-more linked-beneficiary structuring gap, is worth more than three exercises that find nothing. Most institutions run red-team exercises as a compliance checkbox and are quietly relieved when nothing surfaces. Finding a real gap on only the second run, and having it already routed into both the checklist and the implementation note opposite, is what a MAS inspector is actually screening for: not a perfect record, but a functioning feedback loop between testing and remediation.

Jason Lee · Head of Compliance & AI-Driven AML Specialist

The order of these four sections is not incidental, and I'd want a participant to notice that scope comes before data and model, not after. Naming the workflow boundary first, cross-border remittances only, crypto off-ramp plus fiat leg, explicitly excluding domestic transfers and merchant settlement, is what stops an implementation note from quietly scope-creeping into a rebuild of the entire monitoring stack. I have seen exactly that scope creep sink a nine-month project at a bank I advised: an implementation note that started as "fix false positives on remittances" became, six months in, "replace the transaction-monitoring platform," and the original problem was still unsolved when the budget ran out. Solstice Pay's note doesn't make that mistake.

The data-and-model section's clearest sentence is the one about the model output being a preliminary risk band, not an auto-decline. That single design decision is what keeps this whole implementation defensible to a regulator: the cost of a wrong classification is a routing delay to the wrong reviewer, not an unchecked hold on a customer's funds or, worse, a missed genuine structuring case. Every other decision on this page, the override authority, the audit-trail requirement, the red-team cadence, is downstream of that one boundary holding.

Escalation and override is where I'd want a harder look than the note currently gives it, specifically on the manual secondary rule patched in for the linked-beneficiary blind spot. A manual rule bridging a known gap until the model is retrained is the right immediate move, not a permanent one, and this note is honest that it's temporary. What it doesn't yet state, and what I would add before this went to Solstice Pay's board, is a hard date by which that manual rule either gets retired into the retrained model or gets formally reviewed and kept, because manual patches that never get revisited are exactly how monitoring systems accumulate the kind of undocumented exceptions a MAS inspection flags on sight.

Sign-off and review cadence closing the note, rather than opening it, is a deliberate structural choice I'd defend: a reader needs to understand the scope, the mechanics and the escalation path before the ownership split between the analyst and the MLRO makes sense. Monthly review for the first quarter, stepping down to quarterly, is the right cadence for a system this early into a re-baseline, tight enough to catch a bad retraining fast, loose enough not to consume the compliance function's entire calendar.

Jason Lee · Head of Compliance & AI-Driven AML Specialist

The reason this roadmap runs baseline, then integration, then cutover, and not straight to cutover, is that Weeks 1 to 4 produce the one artefact every later phase depends on: a dated false-positive rate measured against the current, un-retrained rules engine before anything changes. Skip that step, and Solstice Pay ends up in the position I have seen more than once, unable to tell a board or a regulator whether a new pairing of vendors actually improved detection or whether the numbers just moved because transaction volume shifted in the same window. I would not sign off on Weeks 5 to 8 starting before that baseline is dated and filed.

The reason patching the linked-beneficiary structuring blind spot sits inside Weeks 1 to 4, alongside the baseline work rather than waiting for the new vendor integration in Weeks 5 to 8, is that a known detection gap does not get to wait for a procurement timeline. A manual secondary rule is a blunt instrument, but it closes the gap this week, not in two months, and that sequencing choice is the one place on this roadmap where I would tell a room to prioritise speed over elegance without hesitation.

Weeks 5 to 8's shadow-mode requirement, running the new paired workflow alongside the existing rules engine without acting on its alerts, is the phase most likely to get compressed under budget pressure, because it produces no visible change to the customer-facing process and looks, from a status update, like nothing is happening. It is nonetheless the phase that prevents the single most common vendor-integration failure I've watched teams make: cutting over to a new system's alert output before confirming it actually catches what the old system caught, and only discovering the gap after a genuine case slips through.

Weeks 9 to 12 is where the entire plan gets tested against its own stated goal, not a generic go-live date. The cutover condition, that detection of the structuring typology must match or exceed the Weeks 1 to 4 baseline before the paired workflow goes live, is the guardrail that keeps "reduce false positives" from silently becoming "reduce alerts" without anyone checking whether genuine detection held. That distinction, a lower false-positive rate that comes from genuinely better precision rather than a quieter, less sensitive model, is the entire point of this course, and re-running the red-team exercise in Week 12 against the live paired workflow, not the shadow-mode version, is what proves it rather than assumes it.

Jason Lee · Head of Compliance & AI-Driven AML Specialist