Uchit Vyas

Work

Loans paid out in under five minutes.

A new lending platform for a leading Asian bank, live in six months.

Client
Leading Asian bank
Years
2021 to 2022
My role
Delivery lead and technical architect
Team
200+ people in 50+ squads
<5min

From application to money paid out.

6months

To a live pilot, 50k users

0

Critical incidents at the pilot launch

The problem

Six months is too short to plan, build and test one after another.

The move

Squads around the platform, all building in parallel.

The result

Pilot live on the agreed date, then nationwide.

Pilot live, 50k users
Nationwide
Discovery
Design
Build and test
Environments
UAT
M3 to M6
Build and test in one agile loop, full team of 200+
By M6
50+ AWS environments
M7 to M8
Five-minute payout proven end to end in UAT

Five minutes, start to finish.

5:00
  1. Customer applies on mobile or web
  2. Pega runs the workflow
  3. FIS risk engine scores the credit
  4. Loan approved
  5. Money paid out

Paid out inside the limit.

People
200+
Squads
50+
Environments
50+
Each squad owned one part of the platform.
How an application moves from the customer’s phone to a payout.

Pega, Go and FIS on AWS.

Workflow and decisions
Pega
Services
Go microservices
Risk
FIS risk engine
Channels
Mobile and web
Cloud
AWS, 50+ environments
Delivery
Containers and CI/CD
The full story

Five minutes, six months, one regulated bank.

The bank’s existing lending process took far longer than five minutes. It wanted a new platform built on Pega for workflow, Go microservices and the FIS risk engine, running on AWS under strict banking rules.

Six months is not enough time to run discovery, design, build and test one after another. Everything had to happen in parallel.

200 people, 50 environments, two languages.

  • Team size. We had to hire and organise more than 200 people across several skill areas, fast.
  • Environments. More than 50 regulated AWS environments had to support parallel development, testing and release without teams blocking each other.
  • Language. Many of the bank’s stakeholders worked in their own language. Misunderstandings were a real delivery risk.
  • New patterns. Running Pega with cloud DevOps in a regulated bank had no standard playbook. We had to design one that would pass audit.

Squads built around the platform.

Three kinds of leadership group worked side by side: delivery leads who owned timelines and dependencies, architects who owned Pega, the risk engine, the microservices and integration, and a PMO group that owned planning, reporting and risk.

Squads were organised around parts of the platform and business capabilities, not around the org chart. We hired for specific skills across Asia rather than for job titles, and set each task’s timeline by the skills of the person doing it.

The bank’s local PMO teams were paired with ours in each region, so decisions happened in the stakeholders’ own language.

Engineering basics were fixed from the start: automated testing, containers everywhere, and mandatory code and pipeline reviews.

What I’d tell the next team.

  • Regulation doesn’t have to mean slow. With the right architecture, automation and governance, a regulated bank moved at startup speed.
  • Past about 150 people, structure is what keeps it working. Leadership groups and squads stopped the programme turning into chaos.
  • DevOps has to come first. Without automation, containers and CI/CD, 50+ environments would have slowed everyone down.
  • Plan by skill, not by job title. Setting each task’s timeline by the person doing it made delivery far more predictable.
  • Talk in the client’s language. Local PMO teams made decisions faster and built trust.
Next case study A safety app that can’t read messages