Navin Benoy

Professional case study · 03

How to make a global product competitive in a market with different rules

A global lending software vendor · Localising a US-built platform for Australia and New Zealand

2 min read

~3 min

Saved per standard PAYG application, delivered.

Income verification: what shipped

Standard PAYG payslipsShipped
Bonus and variable incomeParked for later
Admin screenEach bank enters its own income rules. A policy change needs no new build.

Ship the core. Park the long tail. Let each customer configure the rules.

The situation

The platform was built for US home lending. Lending in Australia and New Zealand runs on different rules, different documents and different ways of assessing a borrower. A US product that left local banks to fill those gaps by hand was not competitive.

The real problem

The local gaps were where banks still did manual work: checking income on payslips, looking up their own credit policy, assessing construction progress payments line by line. Closing those gaps decided whether the product could win locally.

The decision

Build local capability where banks spent the most manual effort, and use AI where it could remove that effort. Prototype first, ship what was ready, park what wasn't.

How to work it

  1. Start where customers are pulling.

    Localisation means meeting rules the US product was never built for. Banks across the UK, Australia and New Zealand asked for income verification first, because each market assesses income its own way.

  2. Test on real data before you commit.

    We tested on real de-identified payslips, and our data scientists measured the accuracy.

  3. Cut the scope to what the technology can finish.

    Every bank treats bonus income differently: some count 80% of it, others 40%. The technology was not ready for that many variations, so we shipped standard PAYG payslips and parked the rest.

    TIP

    When a problem is bigger than today's technology, ship the part you can finish. The technology has moved since, and I would look at the rest again now.

  4. Make the rules settings, not code.

    We built an admin screen where each bank enters its own income rules, so a policy change needs no new build. The first plan used AI to read each bank's policy document. The engineering team was not set up for it, so product and engineering agreed to switch.

    TIP

    Build the capability once and let each customer configure it.

  5. Bring people along with results.

    Bank executives and our own product leads accepted the smaller scope once the first part was live and they could see the benefit.

  6. Prototype the next gaps the same way.

    • Credit policy assistant (prototype): bankers ask questions of their bank's own credit policy while assessing a loan. The policy is the only source, and no customer data leaves the region.
    • Construction drawdowns (prototype): built on a real Australian use case. AI reads builders' budgets and cost schedules to help assess progress payments.

What changed

About 3 minutes saved per PAYG application, delivered. Banks change their income rules without a new build. Two more local use cases taken to prototype.

Use this when

  • You take a product into a market with different rules, and the local gaps decide the sale.
  • An AI problem has a long tail: ship the core and revisit the tail as the technology improves.