One current-account journey, four different rulebooks

01 The situation

A current account is opened by a business, not just a person — so onboarding has to establish both who the business is and who stands behind it. Each of these institutions wanted that journey to work digitally.

Three were large Indian banks. The fourth was a payments platform in the UAE, which meant a different market and a different regulatory context sitting on top of the same basic problem.

02 What made it hard

The problem looked the same four times. It never was.

• Every institution had its own policies, documents and approval rules for the same step
• Business and individual verification had to live inside one journey
• Two markets — India and the UAE — with different regulatory expectations
• Requirements usually arrived as each client’s existing process, not as something engineering could build from

03 What I did

Turned each client’s process into a buildable spec. I sat between the institution and engineering, translating how each one wanted onboarding to work into requirements the team could build against.

Separated what was genuinely different from what only looked different. Some variation came from real policy; some was just wording or order. Telling the two apart kept the build from splintering into four unrelated products.

Stayed with it through delivery. Requirements don’t end at sign-off — I stayed close to the build to answer the questions that only show up once engineering starts.

04 What happened

• Current-account onboarding journeys delivered for three large Indian banks and a UAE payments platform
• Work across two markets and two regulatory contexts
• The analyst-side foundation for the program delivery work I lead today

05 What I’d take into the next one

Map each institution’s policy owners before writing a single requirement. The fastest way to a clean spec is knowing who decides what — not just what the current process happens to be.