Go-Live and First 90 Days

The go-live gate

Not a wish list. A gate. Every line is either true or you are not launching.

PERMISSION
  [ ] Licence held, or partner agreement signed and operative
  [ ] Every data source contracted AND technically integrated
  [ ] Named officers appointed where required (PO and DD are
      DIFFERENT people)
  [ ] Board-approved policies exist and the board has actually seen them

MONEY
  [ ] Ledger balances to the paisa in a full end-to-end test
  [ ] Idempotency verified: same request twice = one posting
  [ ] Concurrency verified: two simultaneous debits, one fundable balance
  [ ] Reconciliation has run clean for a FULL settlement cycle
  [ ] Control totals reconciled, not just row matching
  [ ] Suspense / unapplied account defined, owned, and monitored

RISK
  [ ] Every model in the inventory with owner, tier and validator
  [ ] Independent validation done for high-tier models
  [ ] Kill switch EXERCISED, with the fallback tested under load
  [ ] Fraud rules live in shadow mode with measured precision
  [ ] Sanctions screening tested against transliteration variants
  [ ] Threshold sensitivity analysis documented and approved

CUSTOMER
  [ ] Complaints process live, with the 24h/30d clocks instrumented
  [ ] Escalation paths tested by a human, end to end
  [ ] Vulnerability flags propagate from support to collections
  [ ] Adverse action reason codes verified deterministic
  [ ] Grievance officer named and published

EVIDENCE
  [ ] Decision logging captures model AND policy version
  [ ] Immutable, append-only, with retention set
  [ ] You can answer: "why was this customer declined on date X"
  [ ] You can answer: "which model version made this decision"

OPERATIONS
  [ ] On-call rota with a named owner per system
  [ ] Runbook for: ledger unreachable, provider degraded, model
      disabled, settlement file late
  [ ] Decided IN ADVANCE: reject or queue when the ledger is down

IF ANY LINE IS FALSE, YOU ARE NOT READY.
"We will do it right after launch" is how the first examination
finding gets written.

Launch small, deliberately

The instinct is to launch to everyone and scale. The correct move is the opposite.

• Cap volume for the first weeks — a fixed number of customers per day, not a percentage
• Widen the review queue deliberately. Route far more to humans than you think necessary. You are buying labelled data and finding out where the model is wrong.
• Keep every model in shadow mode alongside the rules that actually decide, until you have measured it on live traffic
• Over-staff support for the first month. The questions you get are not the ones you designed for.

What to watch in the first 90 days

The 30 / 60 / 90 review

Day 30 — is it safe? Reconciliation clean? Any customer harmed? Any control that did not fire? Any model behaving unlike its validation? Fix before growing.

Day 60 — is it right? Now there is enough data to compare assumptions to outcomes. Approval rates against plan. Review queue rate against model. Fraud caught against fraud attempted. Adjust thresholds from measured data, one at a time.

Day 90 — is it a business? Unit economics with real numbers including human review cost. Data cost per approval, not per application. Cohort behaviour. This is the first honest read on whether the model works commercially.

Building the moat, starting now

Everything in Module 0 about differentiation becomes actionable here. The proprietary data that eventually distinguishes you starts accumulating on day one and only if you capture it.

• Outcomes against decisions — every approval, decline, override, repayment, complaint, linked to the decision that produced it
• The reject slice — a small random approval above your cut-off, so you learn what sits just outside it
• Reviewer judgements — every override is a labelled example and a signal about which path is failing
• Abandonment points — where people stopped, and what you asked them immediately before

None of this can be reconstructed later. A year of operating without capturing it is a year of moat you did not build.

The first incident

You will have one. Deciding how it runs beforehand is most of the work.

What tends to go first

• A provider degrades rather than fails — slow responses, stale data, nothing alerts
• A settlement file arrives late, short, or twice
• A model behaves differently on live traffic than in validation
• A support answer is wrong in a way that commits you to something
• A collections message goes out at the wrong hour because a scheduler used the wrong timezone

Running it

1. Stop the harm first. Pause the affected path. Reversing later is cheaper than explaining more of it.
2. Establish facts before communicating. A wrong first statement becomes the story.
3. Assess customer impact by name, not by estimate. Who specifically, and what happened to them.
4. Decide on notification — customer, partner, regulator. Some of these have clocks.
5. Remediate, then write up what would have prevented it.

When to grow

Growth is a control decision, not a marketing one. Signals that you are ready:

• Reconciliation clean for multiple consecutive cycles with exception ageing stable
• Review queue rate flat or falling, and the queue is cleared daily
• Model performance on live traffic within the validated range
• Complaint rate flat while volume rose
• At least one incident handled end to end, with the fix shipped
• Someone other than the founder can run a full day

Signals you are not, whatever the growth pressure: exception ageing rising, review queue growing faster than it clears, complaint rate rising with volume, or any control that has never been tested under load.

A prompt for your own go-live review

You are a fintech operator and risk reviewer who has launched
regulated products in India and been through post-launch examinations.

My situation:
- Product: [describe]
- Licence position: [describe]
- Planned launch date and initial volume cap: [describe]
- What is built: [list honestly, including what is NOT done]
- Team size and on-call coverage: [describe]

Do the following:

1. Go through a go-live gate for MY product specifically. Mark each
   item done, partial, or missing based on what I told you.
2. Name the items that are genuine blockers versus ones I could
   defensibly defer, and say why for each.
3. Tell me what my first incident is most likely to be, given what
   I have described.
4. Give me a 30/60/90 review plan with the specific metrics for my
   product and the thresholds that should worry me.
5. Tell me what I should be capturing from day one that I have
   probably not thought about.
6. Ask me the three questions whose answers would most change your
   assessment.

Be blunt. If my launch date is not realistic given what is missing,
say so and say what would have to change.

Sources

Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.