The data and AI conversation in most financial services organisations is broken in a predictable way. It arrives at the board as a “modernisation programme”, priced as a 24-month commitment with no business case, and then dies a slow death because nobody wants to be the one to kill it, and a quick commercial death because nothing ships. The engineering team becomes overstretched, attempting to fix everything at once. The board, reasonably, asks for a clearer link to outcomes that fail to appear. Eighteen months in, the platform is half-built, the team is exhausted, and the CEO is asking whether the previous architecture was really so bad.

This piece is about how to avoid that arc. The frame is a UK bank or lender: institutional funding, a multi-product platform, regulated, ML-heavy, with sub-ten-second decisioning at its core. The lesson is not technical; it is a discipline of sequencing. Decide value first, win executive sponsorship for the bets rather than for the platform, and then drive the critical path backwards from each bet into execution. The argument is best made in numbers rather than slides.

Why “modernisation” is the wrong word

The first thing to do is to stop saying it. “Modernisation” has no P&L line. It maps to nothing the board can rank against other initiatives competing for capital, and it puts the engineering team on the wrong side of every quarterly review, defending capability against the people who have to fund it.

Every bank or lender I have engaged with has a detailed data strategy and a cloud-native architecture, or a plan to get to one, yet almost none has a list of three data products with a P&L line behind each. That is the diagnostic. Strategy on slides without delivery is theatre, and the cure is not a longer strategy but a shorter list: three named bets, each with a number, an owner and a retirement plan. Anything not on the list is not being built.

The hardest part of saying this out loud is that it is uncomfortable for everyone. The central data team, because it makes their work visibly accountable. The domain VPs, because it asks them to fund and own the products in their domain rather than queue for a central team. The CFO, because three named bets with concrete numbers can fail concretely, where “modernisation” can drift politely for years. That discomfort is an unavoidable part of the work.

A catalogue of value, in money

The reason an FS organisation is a useful setting for this argument is that the arithmetic is readily available. The denominators are large, so small percentage improvements move real money. A starter set of bets, in their pithy form rather than as technical specifications, looks like this.

  • Loan tape, certified. Better data quality compresses the “data uncertainty” buffer that rating agencies and institutional funders apply to anything they cannot verify cleanly. Five basis points off the weighted-average funding cost, across £3 to 4bn of annual originations, is £1.5 to £2m a year. The data product pays for itself many times over, and it shows up in the funder’s bid before it shows up on a slide.

  • Borrower 360. A 200 bps lift in second-product activation among existing borrowers, on a Tier 2 lender base, is an eight-figure annual revenue contribution. The customers are already known to the firm, so the marketing cost is close to zero. Without this single canonical view, the multi-product platform strategy remains aspirational.

  • Credit decisioning feature store. Five points of Gini coefficient, recovered through offline and online parity, translates to millions of pounds of default-loss reduction across the book. Every new product launch, whether the next card, the next credit line or the next embedded partner, can then ship its underwriting models in a quarter rather than two.

  • Fraud signals, unified across products. A 10 bps reduction in fraud loss on a multi-billion-pound book recovers more than a million pounds of margin every year. The cross-product view, in which (for example) a single device opens a credit line and pays a suspicious supplier, catches the mule and bust-out patterns that product-by-product fraud functions cannot see.

  • Partner-facing data product. Embedded distribution propositions, in which the lender’s credit decisioning and servicing stack is white-labelled into a partner bank’s customer journey, are essentially data products sold as APIs. The cleaner and more modular the product, the faster the next partner can be onboarded (months rather than years), and the greater the pricing power the platform brings to the next deal.

  • Regulatory and Consumer Duty reporting. A continuous, contracted data product replaces the quarterly scramble. Cycle time falls by more than half, evidence is produced by construction rather than hand-curated at audit, and the second line stops asking the same question twice.

  • Broker and introducer performance. Submission quality, conversion and default rates by source, surfaced as a product. With forward-flow programmes worth hundreds of millions attached to performance bands, this is not a nice-to-have; it is the basis of the commercial conversation and the lever for incentive design.

Each of these bets shares the same pattern. It lowers cost in basis points across a large book, lifts conversion in basis points across a large customer base, or accelerates time-to-revenue for new initiatives. None of them is a “platform” outcome. Each is a P&L line that the board can rank, fund and verify.

Pick three

The temptation will be to list all of the above. The discipline is to stop at three, or five at the outside.

A short set of selection criteria helps.

  • P&L impact, in money. Not capability, not abstract benefit, but basis points across a known book, conversion lift across a known base, or days of cycle time on a known process.
  • Tractability. The data is already in the building; the work is shaping it into a product, not sourcing it.
  • Dependency depth. Foundational products that downstream bets need (a borrower master, a feature store) earn their place by what they unlock.
  • Optionality. Bets that open up later moves, such as a partner-facing product that doubles as the embedded-distribution spine, earn extra weight.

Apply those criteria honestly and the list almost picks itself. In a bank or lender with institutional funding, sub-ten-second decisioning and a multi-product platform, the first three are very close to the loan tape, the borrower master and the feature store. The fourth, where there is room for one, is the partner-facing data product. Everything else belongs in the next wave, and stakeholders should be told as much. A wish list is not a roadmap.

What the board actually buys

Boards do not buy “we are upgrading our data platform”. They buy “we are building the data foundation for the multi-product platform strategy”, provided that every quarter’s deliverables are tied to an outcome they can verify. The framing matters. Presented as modernisation, the same workstream gets funded grudgingly for twelve months and re-justified annually thereafter. Presented as a portfolio of three named bets with concrete P&L lines and concrete retirement milestones, it gets funded for thirty-six, and the board may ask at month nine whether they should fund a fourth.

The change in language is small but load-bearing. “We will reduce weighted-average funding cost by five basis points within nine months by certifying the loan tape as a data product” is a sentence the CFO can take to the audit committee. “We will modernise our data warehouse” is a sentence the CFO has to defend with hand-waving. The first funds a three-year programme; the second gets cut in the next operating-plan review.

The CEO has a role here too. The pitch lands when the CEO frames it, in their own words, as the foundation for the strategy, rather than when the CTO presents it as a technology choice. The unlock is political as much as architectural. If the executive sponsor will not articulate the bet in business terms, no amount of engineering rigour beneath it will survive the next budget cycle.

Drive the critical path backwards

This is the part most decks skip. Once the bets are picked and the sponsorship is secured, the work is not to “build the platform”. The work is to drive the critical path backwards from each bet into the execution activities that actually deliver it.

For the loan tape, ask: what does the rating agency or institutional funder need to see, contractually, in the next drawdown, in terms of quality SLAs, lineage, schema and refresh cadence? And what upstream chain of producers and controls has to exist for that view to be produced? Walk it back to the source systems. The work that emerges from that exercise is the work to do; everything else can wait.

For Borrower 360, ask: what does the next cross-sell campaign actually need on the day it runs? What does the existing-customer underwriting flow need on the day it ships? Walk it back. The borrower master schema, the consent model, the marketing data join and the deduplication rules all fall out of the use case, rather than the other way round.

For the feature store, ask: which decisioning model is shipping next quarter? Which features does it need served with offline and online parity? What latency and freshness must they hit? Walk it back. The platform components fall out of the model that is about to ship. The team does not build a feature store and then look for users.

This sequencing is the discipline that distinguishes value-led delivery from modernisation. Modernisation builds the platform first and then looks for use cases, almost always finding that the platform shape and the use-case shape do not quite match and that the budget has gone. A value-led approach picks the use case, secures the sponsorship, and drives the critical path backwards into the activities that deliver it. Same engineers, same Snowflake, same dbt, same Iceberg, and a materially different outcome.

A stronger version of the argument is that, run this way, the team discovers early which platform decisions really matter and which were architectural preferences in disguise. Half of the contested choices on most decks evaporate when they are tested against the three bets. The other half become urgent in a way they were not before. The bets are the forcing function for execution excellence, not the other way round.

Behaviours that make it real

Picking the bets is the visible part. The behavioural changes underneath are where the operating model succeeds or fails.

  • The producer is responsible for quality, not the consumer. The “is this number right” tax that typically consumes around a third of analyst time gets pushed upstream, where it belongs. It is the highest-leverage shift in the whole programme.
  • Each domain owns the data products it ships. Origination owns the loan master, capital markets owns the loan tape, the card business owns the transaction stream. Hub-and-spoke only works when the spokes are accountable.
  • Central builds paved roads, not gates. Sensible defaults, with conscious overrides. This is the difference between a centre that enables and one that obstructs.
  • Cost is a first-class engineering concern. Tag everything from day one, publish monthly cost-by-domain, and make cost visible before it is contested.
  • Retirement is a deliverable. Each new data product displaces something. If the team cannot name what gets retired, it is not yet ready to migrate that workload.

Staying focused

Without the discipline of three, the team becomes overstretched. Every domain has a preferred initiative, every analyst has a long-standing request, every executive has an idea from the last conference. The work is not to “build the data platform” but to make the list short enough that the team can ship something, and long enough that it serves the strategy.

The remedies are unglamorous and they work: a roadmap with a hard ceiling of five products in flight at any one time; a quarterly business review with each domain VP that focuses on what shipped and what was retired; an annual Data Value Report that publishes what was spent against what was delivered; and a short, public list of what is not being built. The senior data leader’s job, in practical terms, is to defend that list. New ideas arrive every week; the list does not stretch. Bets that earn a place push something else off.

Sequencing

A defensible sequence for an FS organisation starting now looks something like this.

First 90 days. Honest baseline assessment. Three to five named bets, each with a P&L line and an owner. A central platform team of two or three experienced Snowflake, dbt and Iceberg engineers as the seed. A catalogue stood up with the first fifty data assets. Quarterly business reviews with each domain VP put in the calendar.

First 12 months. Three flagship data products shipped, each tied to its P&L line. One legacy asset retired for each new product shipped. Producer-side quality discipline established. Tagging taxonomy in place from day one. Show-back published monthly. The programme will be net cost on the year, and that is expected.

Months 12 to 24. Scale to fifteen or twenty data products. Embedded data product teams across major domains, co-funded by the centre and the domain. Charge-back replaces show-back once the data is trusted. The programme reaches approximate break-even, and the first annual Data Value Report is published.

Year 3 onwards. Business value visibly outweighs run cost. The platform is generative: new products launch with their underwriting and reporting wired in by composition rather than from scratch. The data conversation has stopped being about cost and started being about which next bet to pick.

Closing

The technology decision is the easy part. The harder part, and the part the board buys, is the discipline of picking three bets, naming them, funding them, and retiring something for each one. That is also the part the team can actually deliver, and the part that makes the difference between a firm with a data moat and one that gets sold to one.

Decide value first. Win sponsorship for the bets rather than for the platform. Drive the critical path backwards into execution. Three named bets, not thirty. The firms that work this way build a data and AI capability incrementally, prove it visibly, and earn their next round of investment from what they have already shipped. The firms that do not are running a modernisation programme, which is what the next operating-plan review will quietly stop funding.