Before, and after each stage
What changes
You already operate the transaction. What you do not yet have is a way to see it as one thing, test a change against it, and know what that change would do to everybody else in it.
This is what a firm holds after each stage, what holding it permits, and what each stage does not reach. Everything named on the left is a document listed on the deliverables page.
What you operate today
A transaction is usually experienced in fragments.
Seller, buyer, warehouse, inspector, bank and insurer each hold a legitimate part of the story. None of them necessarily holds the whole, and none of them failed to.
What is happening today, and what it makes difficult
| What is happening today | What that makes difficult |
|---|---|
| Physical events, documents and instructions move through separate channels | Seeing the actual lifecycle from one end to the other |
| Each party acts from its own systems, records and mandate | Knowing what another party needs before your next action can proceed |
| Controls are spread across contracts, people and routines | Telling an enforceable control apart from a check somebody normally performs |
| Exceptions are resolved case by case | Knowing whether the same gap exists in other shipments or other transactions |
| A change is made inside one team or one system | Seeing how it alters another party’s authority, evidence, timing, cost or exposure |
The problem is rarely that anybody is careless. It is that the transaction has no single inspectable representation of how its parts depend on one another.
After stage one
You can see the transaction as one lifecycle.
What you hold, and what it lets you do
| What you hold that you did not | What that lets you do |
|---|---|
| Transaction map | Put a new operator in front of an artefact rather than an apprenticeship, and settle an internal argument from a shared description rather than from competing memories. |
| Participant-view matrix | Send one page to each counterparty saying this is what we believe about your part, tell us where we have it wrong. People correct statements made about themselves, and it costs them two minutes. |
| Evidence and dependency register | Check the four or five facts that actually gate an act, rather than everything, afterwards. And see which facts are supported by nothing. |
| Bad-day playbook | Answer a lender’s, an insurer’s or a new counterparty’s diligence questions from a document rather than from three people’s recollection. |
| Value and issue register | Take a ranked list of where the days and the cash go to whoever owns the budget, with a baseline they can check against your own volumes. |
You can now ask
Where does this transaction actually slow down, depend on trust, or create avoidable cost?
What stage one does not reach
- Nothing says who may permit anything, and nothing says what must never happen.
- Every statement about a counterparty is still what your firm believes about them, marked as belief, until somebody sends those pages out.
- It is a description. On its own it changes no behaviour.
After stage two
You can design the transaction rather than react to it.
What you hold, and what it lets you do
| What you hold that you did not | What that lets you do |
|---|---|
| State, action and control specification | Say what may happen next from any state, and what must never happen at all. This is also the only form in which a workflow, an integration or a contract could be written faithfully. |
| Authority and evidence policy | Answer who may approve this, up to what limit, and what happens when they are away, from a policy rather than from custom. |
| Exception, dispute and enforcement design | See the rights you hold and never exercise, and the practices you run with no right behind them, side by side. Then decide deliberately rather than by default. |
| Business case and success measures | Take a change to a committee with a baseline, a stated assumption, and what would show the assumption was wrong. |
| What each implementation route would require | Compare four routes including doing nothing, with what each would not solve, before committing to a systems decision that costs many times this engagement. |
You can now ask
If we change this condition, who gains authority, who loses protection, what evidence changes, and what happens to cash, custody and delivery?
What stage two does not reach
- Nothing is enforced. Every invariant is a rule in a document that depends on a person noticing.
- The model has been corrected by you but never run, so it has not yet been able to be wrong.
- Where the model and the operation diverge names obstacles only you can move. It does not move them.
After stage three
You can test the transaction under the conditions it must withstand.
What you hold, and what it lets you do
| What you hold that you did not | What that lets you do |
|---|---|
| Critical-scenario suite | Find out where the description was wrong. A scenario is only a test if it can come back false, and nothing you owned before this could. |
| Role-specific sandbox | Put two of your own functions in front of the same question at the same time, which is frequently the first place they have had to agree in front of each other. |
| Reconciliation and finality demonstration | Test the model against your own systems. If they disagree, one of them is wrong about something real, and nobody has run that test before because there was nothing to run it against. |
| Control-evidence log | Show a lender, an insurer or an auditor what the control is rather than a description of it, including how a reader would know an entry was missing. |
| Architecture fit assessment | Know which parts of your transaction the platform you were about to buy has no primitive for, and would therefore have to live outside the contract where nothing checks them. |
| Build-or-stop analysis | Proceed, redesign, pilot or stop, with what each would require set out and the decision made on evidence you produced rather than on a vendor’s. |
You can now ask
Can our counterparties rely on this control when the physical consequence cannot be undone?
What stage three does not reach
- It runs on a testnet with your data and your parties’ positions, not with your parties. Nothing is in production and nothing is committed.
- A prototype that works is not a system that is ready. The production-readiness gap register exists to say exactly how far apart those are.
- Nobody outside your firm has agreed to anything. That remains true until they do.
Whether it justifies itself
A transaction is worth examining when better control has a financial consequence.
Not savings in the abstract, which nobody can promise before looking. These are the routes through which value appears, each one conditional on the model finding something.
What a mapped and tested transaction is then used for
- Preparing for a facility renewal, stock finance or collateral monitoring
- Onboarding a warehouse, a custodian, an insurer or a new counterparty with clearer requirements
- Assessing whether a process change will release cash, reduce cost or introduce risk
- Making a dispute, a release or a discrepancy review faster and more defensible
- Identifying which controls can be standardised across a portfolio of similar transactions
- Giving operations, treasury, credit, compliance and technology one representation of the same deal
- Deciding whether shared workflow, integration or ledger infrastructure is worth building at all
If the model reveals this, the possible result
| If the model reveals | The possible business result |
|---|---|
| A release condition checked late, or checked twice | Faster movement, lower operating effort and fewer avoidable holds |
| A quantity, custody or evidence gap affecting finance | Stronger borrowing-base confidence, and less capital trapped in uncertainty |
| A recurring exception with no defined owner or rule | Fewer disputes, less senior intervention, lower loss exposure |
| What a new counterparty does to authority and evidence | Faster and safer onboarding, and a more scalable operating model |
| A control that is assumed rather than enforceable | A targeted improvement before a lender, an insurer, a regulator or a customer finds the gap |
| A process change that creates downstream risk | A decision not to fund the wrong automation or integration programme |
When this does not pay
- A one-off transaction. A description amortises over repetition; model something that happens once and you have described an event rather than a process.
- An organisation whose authority is genuinely documented already and current. Stage one may still earn its place for the counterparty view; stage two would be confirming what you have.
- A firm that will not act on it. Documents nobody uses cost the fee and produce nothing. The value and issue register at the end of stage one is the earliest honest signal, and if there is nothing in it worth doing, stopping there is the right outcome.
The first return is usually not automation. It is knowing which change is worth making, which risk is worth removing, and which investment is not yet justified.