In short
Neobank programmes usually fail in the seam between the licence application and the build rather than on technology. The application describes one operating model, the core vendor assumes a second, and the product team designs against a third; nobody compares them until an assurance review somewhere around month seven, by which point changing either the regulatory commitment or the built system is expensive. The programmes that survive treat the application and the architecture as one document maintained by one group of people, so the divergence is caught in weeks rather than quarters.
The failure is organisational, not technical
Post-mortems on stalled banking programmes tend to name a vendor, an integration or a team. Those are usually where the symptom surfaced. The cause is almost always that two workstreams which had to agree were run by people who never had to speak.
A licence application is a detailed description of an operating model: how funds are safeguarded, who approves what, how customers are identified, what happens when a control fails. It is written by regulatory specialists under time pressure, and it makes commitments in prose. The build is a detailed description of the same operating model, written by engineers, in code. Nothing in a conventional programme structure forces those two descriptions to be the same.
Why month seven
The timing is consistent because it follows the shape of the work, not any particular calendar. The first months produce the application and the architecture in parallel, both moving fast, neither yet concrete enough to contradict the other. Build starts. Somewhere between months five and eight the first end-to-end flows exist and the first serious assurance review happens. Internal audit, the regulator's own questions, or a readiness assessment.
That review is the first time anyone reads the commitment and the implementation side by side. The gaps found are rarely subtle: safeguarding described one way and implemented another, an approval step that exists in prose and not in the system, a customer risk model that changed during build without anyone updating the submission.
At that point both options are expensive. Changing the system means rework against a live timeline. Changing the submission means a regulatory conversation nobody budgeted for, and in some regimes it restarts a clock.
What the programmes that work do differently
They run one plan. The regulatory path and the technical architecture are maintained as a single artefact by a group that includes both disciplines, and every commitment in the application has a named owner in the system design. When the build learns something that changes the model, and it always does, the submission is updated in the same week rather than at the next milestone.
They also design the ledger before the screens. Safeguarding, limits, approvals and reconciliation are the things the regulator asked about; they are also the things every product decision inherits. Deciding them early means the application describes something real instead of something intended.
Neither of these is a methodology. They are a staffing decision and a sequencing decision, and both are made in the first month or not at all.
The warning signs, months before
The divergence is visible long before the assurance review, if anyone is looking for it. The most reliable signal is that nobody can name the single person who owns a given commitment end to end. Ask who owns safeguarding. If the answer is a regulatory name and an engineering name, and they have never been in a room together, the gap is already open.
The second signal is vocabulary. Programmes drifting apart develop two glossaries for the same concepts: the submission says "customer due diligence" and the backlog says "onboarding checks", and the two describe overlapping but non-identical processes. When a term appears in one artefact and not the other, it usually means a decision was made in one and never transmitted.
The third is the status of change. In a healthy programme, a build discovery that contradicts the application generates a submission update within days and everyone treats it as routine. Where it generates a note to revisit later, the seam is already being managed by deferral, and deferral compounds silently until the review forces it open.
None of these require an audit to detect. They require somebody whose job is to compare the two descriptions regularly, which is a role most programme structures simply do not contain.
The second most common cause
Where the seam is handled well, the next failure mode is treating the core ledger as a commodity. Choosing it on integration effort, then discovering that its assumptions about postings and limits quietly constrain the product roadmap for a decade. That decision deserves its own analysis, not a vendor scorecard.