Good consumer outcomes are core to the proposition, not a sign-off at the end. There are two ways to fail a customer: leave them behind, excluded or harmed, or leave them on the table, under-served with their value unrealised. Designing for the hardest customer to serve both protects the vulnerable and grows the market, because inclusion and value are the same move. That is the heart of our mission: build the future of finance without leaving the customer behind.
Most outcome work happens after a product is built, when the journey, the wording and the fees have hardened into code, process and cost. By then a poor outcome is expensive to find and slow to fix. We help banks test a proposition against consumer outcomes earlier, while the design is still cheap to change.
The FCA's Consumer Duty expects firms to consider customer needs, characteristics and objectives across the journey, to check that communications are understood, and to evidence those judgements with testing and monitoring rather than assertion. We build that evidence at proposition stage, where it is still a design input and not a post-launch audit. It matters most for agentic journeys: when an AI agent acts for a customer, whether they understood it, agreed to it, and could step in becomes a real outcome question, and our prototype already runs agents under controls with the evidence recorded.
Leave no customer behind, and leave no value on the table. Inclusion and value are the same move, and we design both in.
Protect. Outcomes designed in, not evidenced after harm. And we will tell you when not to automate: a customer making a claim, or asking about their care, needs a person, and an agent that gets between them costs you the outcome and the trust.
Grow. The customer you would under-serve is unrealised value. Reaching the hardest-to-serve customer, and the propositions and markets you never had the capacity to chase, is where the value is. Consumer-outcomes development is not a separate service; it runs through every engagement, proven on the agentic proving ground below.
Consumer outcomes get treated as a sign-off near the end, not a design input at the start.
By the time a proposition reaches an outcomes review, the onboarding is built, the disclosures are signed off and the fee logic is in the system. Learning at that point that customers misread the fee, or could not find support, means reworking running code and process. The FCA has said plainly that firms should find where consumers struggle through testing and customer insight, rather than assume the journey works. The cheapest place to learn it is before the build, on a prototype.
When an agent acts for a customer, the outcome questions change, and most testing cannot reach them.
A focus group can tell you whether a customer understood a screen. It cannot tell you whether a customer understood what an agent did on their behalf, whether they meant to let it, and whether they could step in when it mattered. As banks put agents inside the journey, the Consumer Duty questions move with them: did the customer understand the agent's action, did they agree to it, could a vulnerable customer tell what had happened, and was there a control before anything material occurred?
Our prototype is built to ask exactly those questions, because the agent, the controls and the metrics are already in it. The Family Wealth journey already runs an agent that proposes and a human who must approve before any material action, with the evidence recorded at each step. That is the C3 discipline, Capability, Context and Consent, running in a demonstration today. Put a proposition through it and you are not testing a static mock-up. You are testing how a real person fares when an agent acts under controls, which is the part of the outcome that is about to matter most, and the part almost nobody can test.
Use the prototype to test whether a proposition is likely to deliver good outcomes, before you commit to build.
We have already built a working prototype of a real proposition, with its data, its agent actions and a deliberately simple interface. That same prototype can be put to a second use: a proving ground for consumer outcomes. Bring a proposition into it before you commit to build, and your team defines the target market, the people who might be vulnerable, the core journey, the communications, the support model and the decision rules. Then real people step through the journey in moderated sessions, and the prototype records where understanding breaks down, where friction is heavier than it should be, and where the proposition is likely to miss the outcome it was meant to produce.
This is not a survey or a slide review. It is the same kind of moderated, observed walkthrough the FCA points to when it asks firms to test communications with real customers and act on where they struggle, run early enough to change the proposition rather than defend it. The interface is simple by design and built to be extended, so a proving ground for your proposition is a configuration of something that already works, not a build from nothing.
Five short stages, on one proposition, configured on the prototype rather than built as a programme.
Define the purpose, target market, exclusions, vulnerability hypotheses, pricing assumptions and the outcomes the proposition is meant to produce.
Step through onboarding, eligibility, disclosures, the key choices, the agent's actions and approval gates, support paths, and the exit or complaint flows.
Compare two or three versions of a message, a control, a fee explanation or the way an agent explains what it is about to do.
Record the confusion points, the drop-off moments, the questions people ask, and how confident they felt at each step.
Produce a board-ready view of risks, observed harms, mitigations and the design changes they drove.
Practical outcome lenses, not abstract compliance labels.
Does the proposition reach and suit the customers it was designed for?
Do people actually understand the fees, the limits and the commitments?
Does what a customer pays read as reasonable for the benefit they get?
When a customer needs help, can they find it and resolve the problem?
Where might a vulnerable customer struggle, and does the journey catch them?
Can a customer leave, switch or cancel without an unreasonable barrier?
These exist only when an agent is in the loop, which is why generic testing cannot see them.
Did the customer understand what the agent did for them, and why?
Did the customer agree, and was there a gate before anything material happened?
Could the customer, including a vulnerable one, step in and change course?
The signature output is a misunderstanding heatmap across the journey: the points where people grasped the headline benefit but misread the fee, the cooling-off terms, the support steps, or what the agent had just done on their behalf. These lenses track close to the outcomes the FCA keeps emphasising, products that meet a defined need, communications people understand, fair value, and support that does not create unreasonable barriers. The point is to surface that evidence by testing for it, rather than assuming it away.
Most ways of checking consumer outcomes do one of four things, and this does the one they cannot.
Consumer testing checks a screen or a letter, on near-final assets. Compliance monitoring watches a product after launch, from its own data. Advisory describes what good looks like, in a framework or a report. Agent tooling checks whether an agent stays inside operational rules.
This tests the consumer outcome of an agentic journey, before launch, on a working platform that runs the agent under controls with the evidence recorded. It sits upstream of, and independent of, whatever you build and launch with. What you take away is a vendor-neutral working specification, expressed in standards your vendors already use, not a tool you are locked into.
Evidence you can put in front of a board, not a slide that asserts good intent.
What real people did and said, captured against the journey rather than recalled afterwards.
The outcome risks the testing surfaced, ranked, with the customer groups each one affects.
The specific changes to wording, controls, pricing, support or agent behaviour that reduce the risk.
A view a board can read and a delivery team can act on, generated as you test.
A working specification of the tested proposition, expressed in open standards (ISO 20022, BIAN, recognised control frameworks), so it is portable and reusable across whatever vendor and build you choose.
When the time comes to evidence the proposition to a board, the record already exists, because you generated it while testing rather than reconstructing it afterwards. That is the difference between outcome evidence by construction and a compliance write-up assembled at the end. And because the proving ground is separate from any implementation, the specification you leave with stays yours, ready for whatever vendor and build you take to market.
Pick one proposition heading for delivery, especially one where an agent will act for the customer. We can extend the prototype into a proving ground around it and test whether it is likely to deliver good outcomes before the build hardens.
A note on what this is. The prototype is a working platform, the same one running the demonstrations on this site, including our Family Wealth journey with its agent actions, approval gates and recorded evidence on synthetic data. It is a proving ground by design: it runs with test consumers in proposition and communication testing, never with real customers, and it is not a production banking system. The structured outcome capture and the misunderstanding heatmap are configured, and where needed extended, for the proposition you bring. What you take away is a working specification you can hand to whatever vendor and implementation you choose to build and launch with. Consumer Duty is an FCA framework and its outcomes are the FCA's; we help you test and evidence good outcomes, not certify compliance.
Tell us the proposition, architecture decision, or transformation problem you are facing. We will tell you, honestly, whether and how we can help.
Discuss a challengeField notes on agentic engineering, on-device AI and transformation. No spam, unsubscribe anytime.