In short
- Of the 14 days, only four go to code — the rest is alignment, testing and documentation.
- Most time is lost waiting for test data and keys, not in the technical work.
- Agreeing production thresholds on day one makes the second week far lighter.
Teams usually assume that onboarding a partner bank is bounded by technical complexity. In practice the schedule is set by organisational steps: who issues the keys, when test data is ready, and which department signs off on the result.
Week one: agree the flow
The first week does not start with code. It starts with the flow diagram: where the user enters verification, what they see on a rejection, and when a human operator steps in.
- Days 1–2: agree the flow diagram and the rejection scenarios.
- Day 3: issue sandbox keys and create test accounts.
- Days 4–5: wire up the SDK and run the first check in the sandbox.
Week two: thresholds and production
In the second week the centre of gravity moves from engineering to measurement. Confidence thresholds are tuned against the bank's risk policy, then validated on a small share of real traffic.
- Days 6–8: tune thresholds and verify reporting.
- Days 9–11: pilot on 5% of traffic.
- Days 12–14: full cut-over and handover of the monitoring dashboard.
14
Days, pilot to production
4
Days of pure integration
5%
Pilot traffic share
60+
Connected partners
Where the time actually goes
Three delays repeat: waiting for test data, a security review that drags, and rejection copy that changes on the final day. All three are predictable, and planning for them shortens the schedule.