A parallel run is the part of a statement migration where you receive the same period twice: once as the Swift MT9xx message you already know how to read, and once as the bank's native camt.053. The whole exercise turns on one question, asked every day for weeks. Do the two legs agree? This pack composes three nodes to turn each day's answer into a receipt you can keep, so the parallel run leaves an evidence trail instead of a spreadsheet somebody overwrote.
Stage 1 and Stage 2 each stand up one leg of the pair and check that leg against its own balance equation. Stage 3 is the comparison: it takes the counts and control totals you declare for both legs and reports whether they line up.
The MT-derived leg. A pasted MT900, MT910, MT940, MT942 or MT950 message mapped to a camt.052, camt.053 or camt.054 shaped JSON object, with a fidelity report: truncation findings, unmappable tags, and the 60F + sum(61) = 62F balance-consistency check for statement types. The fidelity report is the part that matters here, because a leg that lost data in mapping is not a leg you can compare.
The bank-native leg. The camt.053 the bank sent for the same account and the same period, with entries classified by Domain, Family and SubFamily per the CGI-MP camt.053 Usage Guide v5.0 and the ISO 20022 ExternalBankTransactionCode1Code registry 2023-03, the OPBD + sum(movements) = CLBD balance equation checked, and a structured-remittance match rate scored.
The both-legs agreement check. You declare, per partition, the record count and control total for each leg plus the tolerance you are willing to accept. The node checks count completeness, value completeness inside that tolerance, and aggregate-versus-partition consistency, so a grand total that reconciles while one partition underneath does not is reported as the inconsistency it is rather than passed silently. Partition by statement day and account, and the report tells you which day drifted.
The three nodes emit their own status vocabularies. This is the reading rule for combining them into one verdict for the day. Apply it yourself, or have an agent apply it: no node emits these three words and the pack does not derive them for you. Keeping the third state visible is the whole discipline, because the state a real parallel run reaches first is usually the one that says nothing yet.
CLEAN, and Stage 3 reports MIGR_COMPLETE. The two declared legs agree on count and on value at the tolerance you declared. This is the day you can file.MIGR_COUNT_VARIANCE, MIGR_VALUE_VARIANCE or MIGR_PARTITION_INCONSISTENT, or one of the legs fails its own balance equation: a failing Stage 1 balance check, or Stage 2 reporting FAILED_BALANCE. A real disagreement was measured, and the per-partition variance figures say where to look.MIGR_INPUTS_REJECTED, MIGR_SAMPLED_ONLY or MIGR_UNDECLARED_TRANSFORM, or Stage 1 reports UNMAPPABLE tags or data loss, or Stage 2 reports LOW_MATCH_RATE. The run supports neither of the other verdicts. This is a result in its own right, not a failure of the pack, and collapsing it into either neighbour is how a parallel run ends up certifying something nobody actually checked.| The receipt proves | The receipt does NOT prove |
|---|---|
| That the camt-shaped object follows from the MT message supplied, and where the mapping lost or could not place a field. | That the MT message you pasted is the message the bank sent, or that it covers the whole period. |
| That the native camt.053 supplied satisfies its own OPBD + sum(movements) = CLBD balance equation, with its entries classified. | That the bank's statement is right, or that its BkTxCd codes describe what really happened on the account. |
| That the declared counts and control totals for the two legs agree, or do not, at the tolerance you declared, partition by partition. | That the declared counts match what either underlying system actually holds. Agreement between two legs from one faulty extract still reads as agreement. |
That a third party can replay the same arithmetic from the same declared inputs and reach the same execution_hash. | That the migration is complete, that a cutover is safe, or that any regulatory duty has been discharged. |
Two dated observations, carried from the nodes themselves rather than restated here as facts of our own.
Swift MT900, MT910, MT940, MT942 and MT950 retirement runs the 2027-28 coexistence window, and camt receive-capability is mandated from 2027-11. That is a dated observation carried from art-563, not a compliance-deadline claim made by this pack. Check the current Swift standards release notes before you plan against it.
Swift provides no MT to ISO 20022 conversion tool, so the translation work sits with the receiving corporate or treasury. That is why a parallel run exists at all: you are proving your own mapping against the bank's, on your own evidence. This pack is independent of Swift and carries no Swift endorsement of any kind.