ASIC and MAS reporting rewrite — JPMorgan Chase

Workflow analysis

Where the bottleneck lived

The failure mode being designed against

Trade books correctlyEvery source value is right

→

⚠ Bottleneck Four layers of transformation Eligibility, mapping, derivation and control each get a chance to change the value

→

The regulator receives something elseAnd a passing source test told you nothing

What replaced it

Requirement written with its testAcceptance criteria defined before the build

→

✓ Trace One representative trade, followed the whole way Booking to repository output, checked at every layer

→

✓ Isolate A failure names its own layer Not “tech issue”. Which layer, with the evidence attached

Ongoing, after go-live

Operations run the new processTrained on the revised flow before the switch, not after

→

✓ Verify The same end-to-end checks, repeated on live flows Go-live is when the reporting starts being real, not when the project ends

Notes

What shaped the decisions

What the downside actually was

Reporting late or wrong is not a missed milestone. It is a breach: penalties, mandated remediation, re-reporting. And over-reporting counts too — submitting trades that were never in scope is equally a breach.

Joined mid-programme, without the domain

I came onto this from process and operations work, not derivatives. The derivatives knowledge had to be learned. The method did not.

Requirements

What had to be true, and why it mattered

Five that carried the most consequence, each with an acceptance criterion attached the day it was written.

01

A trade’s reportability decided by rule, not by assumption

Jurisdiction, reporting entity, product class and lifecycle event resolved before anything else runs.

This fails in both directions. Reporting a trade that should not be reported is as much a breach as missing one that should.
Eligibility · the first question in the chain
02

Every required value traced back to where it is created

Identifiers, leg-level notionals, timestamps, action types. Does it exist upstream, need deriving, or not exist at all?

You cannot map a field you have not located. The gaps found here are the entire technology change list.
Source analysis · before any mapping
03

Conditional fields populated only when their condition is met

Required under some product, entity or event combinations and not others, with the trigger written down.

A field only sometimes required is a field only sometimes tested, which means production is where it gets found.
The row that causes the most defects
04

Legacy records assessed before they were migrated

For historical trades: carry the stored value across, derive it from what exists, or correct it and re-report?

A forward-looking change is a build. Remediation is archaeology with a regulatory deadline attached.
Legacy re-reporting under the 2024 Rules
05

Exceptions surfaced rather than passed through silently

Missing or anomalous data raises a break before submission, instead of flowing through unnoticed.

A rejection is recoverable. An accepted but incorrect submission is the one nobody notices until a regulator does.
Integration control · the last safeguard

Method

Four layers, and every one of them can lie

Described by function rather than product name. What matters is not what the systems are called, but that there are four places a value can change between booking and the regulator.

The reporting chain, and where the work sat across it

Four layer reporting chain from trade capture through eligibility and mapping and integration control to the trade repository, with the exception loop and the three roles

Read the rule at the level it bites. Which trade, which product, which entity, which event, which leg. A document-level reading misses the build.

Decide the population before mapping anything. Mapping fields for trades that were never in scope is wasted build and a breach in the other direction.

Trace each value to its source. Present, missing, or derived. This is the step that gets skipped when a deadline is tight.

Write the acceptance criterion with the requirement. Same document, same day.

Prove it on a real booked trade. Every layer, exception branches included, then again on live flows after go-live.

Worked example

The first question, and then one data element all the way down

Two things decide whether a regulatory report is right. Whether the trade should be in the population at all, and whether each value survives the journey. Here is one of each, in full.

Reportability decision tree: six sequential questions, each with an exit, ending in a reportable outcome and the values that must then be carried — Reportability decision logic — reconstructed from the published rules and the decision points used on the programme, not a copy of the internal artefact

Why eligibility is built first and assumed last

Question four is the one people skip. An exclusion that applies but was never documented looks identical, in a review, to a trade that was missed. The evidence is the deliverable, not the decision.

Then one value, followed the whole way

Both counterparties must submit the same UTI, and the repository uses it to pair the two sides. If they do not match, one trade looks like two unrelated one-sided reports.

The Unique Transaction Identifier: four questions to answer, four ways it fails, what each failure looks like downstream, and the four checks needed to prove it — Four questions, four failure modes, and why “accepted” is not the same as “correct”

The failure mode that has no alarm on it

Three of those four announce themselves. A reformatted identifier does not. It is well-formed, passes every check, gets accepted, and simply never pairs. It surfaces in a reconciliation weeks later, by which point the whole population has it.

So the test could not stop at a successful submission. Accepted, paired and stable across the lifecycle are three separate assertions, and only the first is easy.

Findings

Six questions, answered in order

Each diagram below is the working, redrawn for this page. All of them describe method rather than proprietary design.

01How does a rulebook become something an engineer can build?

Seven steps from regulatory rule through eligibility, data requirement, source analysis, gap and mapping to a technology change with acceptance criteria — Rule to buildable change, and the three parts of the change request that resulted

What it showed

The value is in the order. The acceptance criterion is written with the requirement, not after the build — otherwise the test becomes a description of whatever got delivered.

02Where does each required value actually come from?

Source to target requirement matrix across product classification, identifiers, transaction economics, leg level data, lifecycle actions and conditional fields — Representative element categories, what had to be decided for each, and what proves it

What it showed

Each category fails differently. The bottom row generates the most defects: a conditional field is only tested when someone deliberately constructs the condition, and if nobody does, production constructs it for you.

03Does the meaning survive all four layers?

One representative trade followed from booking through capture, eligibility, controls and repository output, with the question asked at each stage — One trade, followed the whole way, with the specific question asked at each stage

What it showed

A source-system test passing tells you the source system works. It tells you nothing about what the regulator will receive.

04When something fails, which layer broke?

Five layers to isolate before raising a defect, what every defect carried, and the prioritisation rule — Isolate the layer, attach the evidence, then raise it

What it showed

“It does not work” is a handover of confusion, not a defect. Tracing it first turns it into a decision, addressed to whoever can act. Priority is set by regulatory impact, not by volume of complaint.

05What about the trades that were already booked?

One rewrite splitting into a new trade stream and a legacy remediation stream, with the remediation path when data does not map cleanly — Two streams from one rule change, and why the second one is harder

What it showed

New trades are a design problem. Legacy records cannot be re-booked, so each attribute needed a decision: migrate, derive, or correct and re-report. The regulator publishes a section on this, which tells you clean migration is the exception.

06How do you protect a date you cannot move?

Three constraints, the five questions that set defect priority, and the weekly technology and operations huddle agenda — Fixed date, finite build capacity, and testing hours as the scarcest resource of the three

What it showed

The expected constraint is engineering capacity. The real one was Operations, still running the desk. Their hours were finite and non-renewable, which made test sequencing a project-management decision rather than a testing one.

Why this is the finding, not a footnote

Every one of these six is the same discipline applied at a different altitude: do not accept a statement you have not traced. Not the rule, not the mapping, not the passing test, not the defect report, not the plan. In a programme where being wrong is a regulatory event rather than an inconvenience, that is the whole job.

The other half of the role

The regulatory work had a deadline. The automation work had a queue.

Alongside the rewrite I ran a digital initiative on the desk itself: taking repetitive data collection and reporting off people and putting it into tooling. Different problem, different pace, same underlying question about where effort is being wasted.

Different problem, same discipline

The regulatory programme was externally imposed, fixed-date and unforgiving. The automation work was internally chosen and easy to defer. The discipline that gets a regulator’s date met is the same one that stops a good automation idea dying in a backlog.

The result

What was actually at stake

The value of this work is not a saving. It is the list of things that did not happen.

Each failure mode, and what it costs a reporting entity under the 2024 Rules
If it had gone wrong	What follows
Live after the commencement date	Breach of the reporting obligation from day one, across every affected trade
Eligible trades missing from the population	Under-reporting. Remediation and back-reporting of everything affected
Ineligible trades reported	Over-reporting. Equally a breach, and it distorts the regulator’s view of the market
Wrong values accepted by the repository	The worst case. No rejection, no alert, and an inaccurate regulatory record standing until a reconciliation finds it
Legacy records left unmigrated	The historical population stays wrong under rules that now apply to it

None of those happened

The scope went into production against the regulatory timeline, with eligibility logic deciding the population in both directions, mapping traced to source, exceptions surfacing rather than passing through, legacy records assessed rather than assumed, and the same end-to-end checks repeated on live flows after go-live.

Written to be publishable

This page names no internal application, no internal team, no colleague and no trade. The reporting chain is described by what each layer does rather than by what it is called. ASIC, MAS, DTCC GTR and the 21 October 2024 commencement date are all matters of public record, and everything else has been left out on purpose.

What shipped

What produced each result

Three deliverables, and each one maps to a claim at the top of this page.

Produced the 21 Oct 2024

The critical path, actively defended

A project charter and schedule tied to the regulatory date, RAG reporting that surfaced blockers before they became late-stage surprises, and a weekly huddle where severity was argued on regulatory impact rather than volume. Scarce Operations testing time was scheduled as the constrained resource it was.

Produced the 2

One requirement set covering both regimes

ASIC and MAS analysed together rather than sequentially, so shared data elements were specified once and jurisdictional differences were treated as conditions on a common requirement rather than as two parallel builds.

Produced the 4

End-to-end test design and defect isolation

Scenarios that followed a representative booked trade through every layer to the repository record, exception branches tested rather than assumed, and a defect workflow that named the failing layer with evidence attached before anything was handed to Technology.

What I would do differently

Front-load the conditional fields and the exception branches. They were tested, but they were tested after the happy paths, and they are where regulatory reporting actually breaks. A field required only under a specific product and event combination will not surface on its own; someone has to sit down and deliberately construct the condition. Doing that early would have moved several discoveries out of the pressured end of the schedule.

A trade booked right could still reach the regulator wrong

What I achieved, role by role

Trade reports to ASIC and MAS were assembled by hand against a deadline set by the regulator, and a wrong report is a reportable breach.

What I personally did on this

Regulatory prose in. Buildable behaviour out.

Where the bottleneck lived

What shaped the decisions

What had to be true, and why it mattered

Four layers, and every one of them can lie

The first question, and then one data element all the way down

Six questions, answered in order

The regulatory work had a deadline. The automation work had a queue.

What was actually at stake

What produced each result

The critical path, actively defended

One requirement set covering both regimes

End-to-end test design and defect isolation

How it was actually done