Controlled delivery
Controlled delivery, from risk context to working system
Most fintech delivery problems are not engineering problems. They are the result of building before the risk position, the decision owners, or the failure routes were settled. The sequence below is designed to make that impossible: each stage closes with a written gate, and the next stage does not open until the gate clears.
What it costs
Two or three weeks at the front of an engagement that would otherwise be spent guessing.
What it leaves
A written trail of decisions, criteria, and rejected options that outlasts the engagement.
- 01
Risk context
- 02
Workflow model
- 03
Technical shape
- 04
Implementation brief
- 05
Handover support
Why gates
A gate is a written agreement, not a meeting.
Stage gates fail when they are treated as status checkpoints. Ours are conditions: a specific statement that must be true and recorded before work continues. If a threshold has no owner, the workflow model gate does not clear. If a technical decision has no stated criteria, the architecture gate does not clear.
This slows the first two weeks and saves the following three months. It also means that when something is challenged later — internally, by an auditor, or by a partner — the basis for the decision already exists in writing rather than being reconstructed from memory.
The condition is recorded and work continues to the next stage.
The blocking question is named, owned, and given a date.
A later finding invalidates an earlier decision, so it is retaken.
Five stages
The sequence in full.
Each stage states what it produces, what it needs from you, and the condition that closes it. Nothing is inferred and nothing carries forward unrecorded.
- Stage 01
Risk context
Establish what is actually at stake before proposing anything.
We start with the exposure: what money, data, and obligations pass through the workflow, which parts are already under scrutiny, and what would go wrong if a step failed silently. This is a short, direct phase built on existing documentation and conversations with the people doing the work.
Produces
- Risk context note
- Constraint list
- Stakeholder and decision-owner map
Needs from you
- Existing policies and procedures
- Current tooling access or walkthrough
- Operational team time
Gate: Exposure and obligations are written down and agreed.
- Stage 02
Workflow model
Map the product, workflow, and data requirements as they must operate.
The workflow is modelled as states, transitions, and decisions rather than as screens. Each decision point records who owns it, what evidence it needs, and what happens on the unhappy path. Data requirements fall out of this naturally: if a decision needs a fact, that fact needs a source.
Produces
- Workflow state model
- Decision and threshold definitions
- Data requirement list
Needs from you
- Risk context note
- Operational walkthroughs
- Existing data model where available
Gate: Every decision point has an owner, a threshold, and a defined failure route.
- Stage 03
Technical shape
Design the software or process architecture that carries the model.
With the workflow settled, the technical shape can be decided: components, boundaries, integrations, access, and logging. Where a build is not the answer, the same rigour applies to process design instead. Options are scored against the constraints from stage one, and the rejected options stay in the record.
Produces
- Architecture note
- Integration and interface inventory
- Access and logging design
Needs from you
- Workflow state model
- Platform and vendor constraints
- Security and data boundary requirements
Gate: Architecture decisions are documented with criteria and rejected alternatives.
- Stage 04
Implementation brief
Turn the design into something a team can build against.
The brief is the deliverable most engagements are judged on. It carries scope in phases, acceptance criteria per phase, open questions with owners, and the assumptions the design depends on. It is written so that an engineering team — ours, yours, or a partner's — can start without a second discovery cycle.
Produces
- Implementation brief
- Phased scope with acceptance criteria
- Assumption and open-question register
Needs from you
- Architecture note
- Delivery capacity and timeline constraints
- Commercial or regulatory deadlines
Gate: Scope, acceptance criteria, and open questions are agreed in writing.
- Stage 05
Handover support
Support the build, the handover, or the partner executing it.
Involvement after the brief is agreed explicitly rather than assumed. It can mean building the software, reviewing increments against acceptance criteria, or supporting an internal team through the phases. Every route ends with a handover pack rather than a conversation.
Produces
- Delivered increments where build is in scope
- Review notes against acceptance criteria
- Handover pack
Needs from you
- Implementation brief
- Delivery team or partner
- Agreed review cadence
Gate: Handover pack is delivered and the remaining owners are named.
Engagement shape
Stop where it makes sense.
Engagements are scoped to a stage range. Continuing past it is a separate decision, not an assumption built into the first agreement.
- M-1Stages 01 – 02
Workflow review
An existing process is examined and modelled. Findings are prioritised by exposure rather than by effort. Ends with a review note and a decision on whether further work is warranted.
- M-2Stages 01 – 03
System plan
Adds the technical shape: components, integrations, access, and logging, with the options considered and rejected recorded alongside the recommendation.
- M-3Stages 01 – 04
Implementation brief
The full written package: phased scope, acceptance criteria, assumptions, and open questions. Written to be handed to an internal team or a delivery partner without a second discovery cycle.
- M-4Stages 01 – 05
Build and support
Software delivered against the brief, or review and support while another team delivers it. Closes with a handover pack and named owners for anything still open.
What we ask for
The sequence only works with honest inputs.
- Access to the people who currently perform the work, not only those who manage it
- Existing policies, procedures, and process notes in whatever state they are in
- A walkthrough of the current tooling, or read access where that is straightforward
- One named decision-maker who can close a gate
- Honesty about constraints — deadlines, commitments already made, and internal disagreement
No fixed template
No mandatory tooling
No long discovery phase
Operating principles
- P1
Risk-aware by design
Exposure is identified before architecture, not discovered during a review. Where a workflow touches money, identity, or an obligation, that fact shapes the design from the first sketch.
- P2
Software should match the operating model
A system that assumes a team structure you do not have will be worked around within a month. Software is designed for the roles, capacity, and decision rights that actually exist.
- P3
Compliance workflows must be usable, not just documented
A control that is technically present but impractical to perform is a control that will be skipped. Queue design, thresholds, and evidence capture are treated as usability problems.
- P4
Product, risk, and engineering need a clear handover
Most fintech delivery problems are handover problems. Each stage closes with a written brief so the next group inherits decisions rather than reconstructing them.
- P5
Build practical systems, not abstract recommendations
A recommendation nobody can act on has no value. Work ends in models, specifications, and briefs precise enough to build or operate against.
Placing the work
Which stage does your problem actually sit in?
Send the context and we will tell you where we would start — including if the honest answer is that you do not need stages three to five.
info@riskflowdigital.com