Your Team Got Faster. Your Product Didn't: The Ceiling APAC Fintech Scale-Ups Hit in 2026
Executive Summary
Something has gone quietly wrong in the engineering organizations of APAC fintech scale-ups, and the usual diagnostics do not detect it. Headcount is stable. Tooling is better than it has ever been. Individual engineers are demonstrably more productive. And delivery has not accelerated.
The most complete recent evidence on the mechanism comes from GitLab's AI Accountability Report, published in June 2026 - a vendor-published study, and read here as directional rather than authoritative for that reason. In it, 78 per cent of developers report faster code output with AI tools and 73 per cent report better code quality. Yet 79 per cent say the overall software delivery process has not kept pace with the speed of coding, and 85 per cent agree that AI has moved the bottleneck from writing code to reviewing and validating it (GitLab, 2026).
The same report contains the finding that ought to concern a board more than any productivity number. 87 per cent of respondents were confident they could determine an AI-generated component's role in a production incident within 24 hours. Among organizations that had actually experienced such an incident, only 34 per cent could (GitLab, 2026).
Independent data points the same way. Across the 2025 Stack Overflow Developer Survey, more than 84 per cent of developers were using or planning to use AI tools, while trust in those tools fell to 29 per cent - down 11 percentage points from 40 per cent in 2024 (Stack Overflow, 2025; analysed February 2026). Adoption rose and confidence fell, which is not how technology adoption curves normally behave.
Now place that against what APAC supervisors began asking for this year. APRA wrote to industry on 30 April 2026 reporting the findings of targeted engagement with larger authorized deposit-taking institutions, insurers and superannuation trustees, and observed that assurance practices are lagging the complexity of AI adoption, with overreliance on vendor presentations and summaries without sufficient examination of key risks. It set expectations for board-level AI literacy sufficient for "effective challenge and oversight", human accountability in high-risk decisions, and continuous, proportionate second-line assurance (Australian Prudential Regulation Authority, 2026). ASIC followed on 8 May 2026, telling licensees not to wait for perfect clarity and directing that its letter be tabled at board and risk committees (Australian Securities and Investments Commission, 2026).
Two forces, one direction. The volume of change an engineering organization can produce has risen sharply. The volume of change it can evidence has not moved. That second number is the real capacity of the business, and this piece gives it a name: the attestable change ceiling - the maximum rate at which an organization can put change into production while remaining able to answer, on demand, where each change came from, why it was made, who approved it, and who owns it in production.
Below the ceiling, engineering velocity converts into product. Above it, additional velocity converts into unreviewed inventory, and eventually into an incident nobody can reconstruct. Most APAC fintech scale-ups we encounter are running above their ceiling and measuring the wrong side of it.
Introduction: The Wrong Answer to the Right Question
Ask a fintech CEO in Singapore, Sydney or Kuala Lumpur what is holding engineering back and you will usually get one of four answers: we cannot hire fast enough, our platform is creaking, compliance slows everything down, or we have too much legacy.
Those are honest answers, and they were largely correct until about eighteen months ago. They are now describing symptoms of a single underlying condition, which is that the organization's ability to generate change has decoupled from its ability to account for change.
This matters more in financial services than anywhere else, because in a supervised business the two are not separable. A payment feature is not shipped when it works; it is shipped when it works, is evidenced, is approved by someone with authority to approve it, and can be explained later to a regulator, an auditor or a board. Everywhere else in software, evidence is overhead. Here it is part of the product.
That is why the AI productivity story lands differently in BFSI than in consumer technology. A general software company that doubles its code output and holds its review capacity constant accumulates technical debt. A regulated fintech that does the same accumulates unattestable debt - and unattestable debt is not a quality problem, it is a licensing problem.
Industry Context: Money Is Flowing Into a Bottleneck
The spending environment is not the constraint, which is precisely what makes this interesting.
Forrester's Asia Pacific Tech Forecast 2026, published on 26 March 2026, projects regional technology spending growth of 9.3 per cent in 2026, with software the second-fastest category at 10.7 per cent, behind computer equipment at 13.7 per cent. Growth is highly uneven across the region: Vietnam at 15.4 per cent and the Philippines at 12.3 per cent lead, Malaysia at 9.5 per cent, with Australia and Singapore both at around 6 per cent and India at 4 per cent. Forrester's own caveat is the important part: software inflation, hardware volatility, regulatory fragmentation and talent shortages will erode how much that spending actually buys (Forrester, 2026).
Appetite is not the issue either. In Money20/20 Asia's Future of Fintech in APAC study of more than 130 senior fintech leaders across Asia, published 3 March 2026, 61.2 per cent of organizations had already adopted AI or machine learning and only 3.5 per cent had not begun exploring it. The same cohort ranked fraud prevention as their highest operational priority, at 63.5 per cent (Money20/20 Asia, 2026).
Read those two together and the picture is a region spending strongly, adopting quickly, and pointing its highest-priority engineering effort at exactly the domain - financial crime - where every decision must be explainable after the fact.
Supervisors are moving into that same space rather than standing back from it. On 4 May 2026 MAS announced a Proof-of-Value with the Government Technology Agency of Singapore, the Singapore Police Force and five banks, applying AI and machine learning techniques to pre-emptive scam detection, with account numbers hashed and data deleted at the conclusion of the exercise (Monetary Authority of Singapore, 2026). The design of that exercise is itself instructive: the controls were specified alongside the capability, not after it.
Current Challenges: Four Pains, One Ceiling
The four answers executives give are worth taking seriously, because each of them is a genuine pain - and each one turns out to be the same pain viewed from a different seat.
"We cannot hire fast enough." Yesterday's analysis set out where regional engineering capacity has gone, and we will not restate those figures. The relevant point here is narrower: hiring relieves a shortage of production capacity. If the constraint is review, evidence and approval capacity, additional engineers make the queue longer, not shorter. This is the most expensive misdiagnosis available to a scale-up, because it is the one the board is most willing to fund.
"Our platform is creaking." Usually true, and usually second-order. A platform that cannot produce a clean audit trail of what changed, when, by whom and why is not a performance problem; it is a ceiling problem wearing a performance costume.
"Compliance slows us down." What actually slows the organization down is compliance arriving late. Requirements that are known at design time and applied at release time convert into rework, and rework is where scale-up delivery timelines disappear. APRA's observation about firms relying on vendor presentations rather than examining the underlying risks is the same failure at a different altitude: the assurance was assumed rather than built.
"Too much legacy." For a Series B or C fintech this is rarely literal legacy. It is more often three years of accumulated change that nobody can now explain, which behaves exactly like legacy and is generated far faster when code output rises without review capacity rising with it.
The GitLab confidence gap - 87 per cent sure they could trace an AI-generated component's role in an incident, 34 per cent actually able to when it happened - is the clearest available measurement of the distance between the ceiling an organization believes it has and the one it really has (GitLab, 2026).
Key Trends: What 2026 Changed
Review became the scarce function, and it is the one function that does not scale by hiring juniors. Validation of change in a regulated context requires context, seniority and accountability. The market has spent two years optimizing the abundant half of the process.
Trust and adoption decoupled. Rising use alongside falling trust (Stack Overflow, 2025) tells you engineers are shipping code they are themselves less certain about. In a regulated perimeter, that uncertainty has to be absorbed somewhere, and it is absorbed in review.
Supervisors moved from frameworks to evidence. Both Australian regulators wrote to industry within nine days of each other, and neither created a new AI rulebook. Both applied existing obligations and asked what firms could demonstrate. The engineering consequence of an evidence-based supervisory posture is that provenance, approval and ownership become product requirements.
The competitive question changed shape. In 2024 the question was whether you could build it. In 2026, for a regulated APAC fintech, the question is whether you can build it, evidence it, and still be moving at the end of the quarter.
Strategic Analysis: The Attestable Change Ceiling
The attestable change ceiling is the maximum rate at which an organization can put change into production while remaining able to answer, on demand and for any individual change: where it came from, what it was for, who approved it, and who is accountable for it in production.
It is worth adopting as a managed number for three reasons.
It is the only capacity figure that is honest in a supervised business. Deployment frequency measures what left the building. The ceiling measures what left the building defensibly. A team deploying forty times a week with an evidence trail for twelve of them does not have a velocity of forty; it has a velocity of twelve and a liability of twenty-eight.
It reframes the hiring conversation immediately. Once the ceiling is visible, the question stops being "how many engineers do we need" and becomes "which of these two capacities is binding" - and the answer determines whether the next dollar goes to a squad, to a platform team, or to automating evidence generation. Those three investments have very different payback profiles and are routinely confused.
It converts a compliance argument into an engineering argument, which is the only form in which it gets funded. Boards do not fund "better governance". They fund removing a constraint on shipping. It happens to be the same work.
The mechanics of raising the ceiling are unglamorous and well understood. Change provenance captured automatically rather than reconstructed. Approval routed by risk class rather than uniformly. Evidence produced as a by-product of the pipeline rather than assembled by a human before an audit. Ownership recorded at merge, not inferred from a wiki. None of this is novel engineering. It is ordinary engineering that is almost always scheduled last, because until recently the production side was the constraint and this side had slack. The slack is gone.
The honest counter-argument. For a pre-product-market-fit fintech, none of this applies, and imposing it early is a good way to die slowly and tidily. The ceiling only binds when the business is regulated, is scaling, and has more than one team touching the same production estate. Before that point, speed genuinely is the strategy. The failure mode we see is not firms that start too late by a little - it is firms that cross all three thresholds in a single quarter and do not notice.
Real-World Examples
A regional payments scale-up that hired into the wrong constraint. The pattern is familiar enough to describe generically. Delivery slows; the board approves a hiring plan; headcount rises materially over two quarters; throughput does not move. The queue was never at the keyboard. It was at a small number of senior reviewers who were also the only people who could sign a change into a supervised environment. Adding producers to a system constrained at approval lengthens the queue and lowers morale on both sides of it.
The Singapore scam-detection Proof-of-Value as a design pattern. The MAS exercise announced on 4 May 2026 is a useful public example of the opposite behaviour - hashing and deletion specified as part of the exercise design rather than added afterwards (Monetary Authority of Singapore, 2026). Whatever the eventual outcome, the sequencing is the lesson: controls that arrive with the capability cost a fraction of controls retrofitted to it.
The Australian supervisory signal, read as an engineering brief. Strip the governance language from the APRA and ASIC letters and what remains is a list of things a system must be able to produce: what the model does, what data it touched, who approved its use, what happens when it fails, and who is accountable. Firms that can generate that from their pipeline will answer in days. Firms that cannot will answer in months, and will spend those months not shipping. That is the ceiling, expressed as a supervisory conversation.
Actionable Recommendations
Measure both numbers this month. Count changes deployed to production in the last 90 days. Then count how many of those you could produce full provenance, approval, and ownership for within one business day, without asking an individual to remember. The ratio is your ceiling utilization. Most scale-ups have never calculated it, and the first calculation is usually the most useful hour of the quarter.
Name an owner for the ceiling. Not a compliance owner - an engineering owner, with a roadmap and a budget. Where this sits with nobody, it is nobody's number, and it does not improve.
Route approval by risk class before you add reviewers. Uniform approval is the most common reason senior engineers become a bottleneck. Most changes do not need the scrutiny that a small minority genuinely do, and separating them typically buys more capacity than a hire.
Make evidence a build artefact. If a human assembles the evidence pack, the ceiling is set by that human's calendar. Generated at merge, it is set by the pipeline.
Decide deliberately where AI-generated change is permitted, and record it. Not a ban and not a free pass - a documented risk classification, so that the answer to a supervisor's question exists before the question is asked. The detailed governance architecture for this is the subject of our Week 4 series and is out of scope here.
The sourceCode Perspective
We build and run engineering teams for banks, insurers and fintechs across Australia and Southeast Asia, so the bias is declared: we are called in more often when the ceiling has already been hit than when it is being planned for.
What we observe is that this is not a tooling problem, and firms that treat it as one buy a platform and stay stuck. The organizations that raise their ceiling do something structurally duller: they make provenance, approval and ownership the standing responsibility of a permanent platform team, and they measure the ratio above monthly, in the same review as deployment frequency. It is not a project. It is a number that somebody owns.
The caveat is the one in the counter-argument. If you are pre-scale and unsupervised, ignore all of this and go faster. The moment you are neither, the ceiling is already your capacity, whether or not anybody has measured it.
Conclusion
The scale-up engineering story of 2026 is not that AI failed. Individual engineers are faster and, on their own account, producing better work. The story is that the constraint moved while the org chart, the budget and the board slide all stayed pointed at the old one.
Seventy-nine per cent of developers say delivery has not kept pace with coding. Eighty-five per cent say the bottleneck is now review and validation. Eighty-seven per cent believe they could reconstruct what happened in an incident; thirty-four per cent of those who have actually been there could.
For a regulated fintech in APAC, those numbers describe a ceiling. It is measurable, it is nobody's job by default, and it is almost certainly lower than your board thinks.
Two questions are worth putting on the next leadership agenda. What is our attestable change ceiling? And who owns raising it?
Know your ceiling before you approve the next hire. The ratio that matters - deployed changes versus changes you could fully evidence within one business day - is calculable from your own data today. Our Insourcing Cost Calculator models whether your next investment belongs in a squad, a platform team, or in automating evidence generation, against your current mix and target markets.
Run the numbers: Insourcing Cost Calculator →
And tell us where it hurts. Today's poll runs on the sourceCode page all week: Biggest engineering pain in your fintech scale-up right now? - Hiring the right engineers · Review and release bottlenecks · Audit and evidence overhead · Platform and legacy debt.
Frequently Asked Questions
What is the attestable change ceiling? The attestable change ceiling is the maximum rate at which an organization can put software change into production while remaining able to answer, on demand and for any individual change, where it came from, what it was for, who approved it, and who is accountable for it in production. It is distinct from deployment frequency, which counts changes released without regard to whether they can be evidenced.
Why has AI not made software delivery faster in financial services? Because AI accelerates the production of code without accelerating review, validation, approval and evidence. In GitLab's June 2026 AI Accountability Report, 78 per cent of developers reported faster code output while 79 per cent said the overall delivery process had not kept pace, and 85 per cent agreed the bottleneck had shifted from writing code to reviewing and validating it. In regulated financial services the downstream steps cannot be skipped, so the gain is absorbed before it reaches the customer.
What did APRA and ASIC tell Australian financial institutions about AI in 2026? APRA wrote to industry on 30 April 2026, reporting from targeted engagement with larger authorised deposit-taking institutions, insurers and superannuation trustees that assurance practices were lagging the complexity of AI adoption and that firms were over-relying on vendor presentations without sufficient examination of key risks. It set expectations covering board AI literacy, human accountability in high-risk decisions, third-party concentration risk and continuous proportionate second-line assurance. ASIC wrote on 8 May 2026, urging licensees to act without waiting for perfect clarity and directing that its letter be tabled at board and risk committees. Neither regulator created AI-specific rules; both applied existing obligations.
Do developers trust AI coding tools? Adoption and trust have moved in opposite directions. In the 2025 Stack Overflow Developer Survey, more than 84 per cent of respondents were using or planning to use AI tools, while trust in the accuracy of those tools stood at 29 per cent - down from about 40 per cent in 2024.
What is a platform team? A platform team is a permanent engineering team whose product is the internal capability other teams build on - pipelines, environments, deployment, observability and, increasingly, the automatic capture of change provenance and approval evidence. It is distinguished from a project team by being funded continuously rather than per initiative.
What is change provenance? Change provenance is the recorded origin and history of a specific change to a production system: what was changed, by whom or by what tool, for what purpose, under whose approval, and when. It is the primary input to any post-incident or supervisory reconstruction.
What is second-line assurance? Second-line assurance is independent risk oversight performed outside the team that owns the activity, testing whether controls are designed and operating effectively. APRA's April 2026 letter set an expectation of continuous and proportionate second-line monitoring of AI use by regulated entities.
How fast is technology spending growing in Asia Pacific in 2026? Forrester's Asia Pacific Tech Forecast 2026, published 26 March 2026, projects regional technology spending growth of 9.3 per cent in 2026, with software growing 10.7 per cent. Country growth rates vary widely, from about 4 per cent in India and 6 per cent in Australia and Singapore to 12.3 per cent in the Philippines and 15.4 per cent in Vietnam. Forrester cautions that software inflation, regulatory fragmentation and talent shortages reduce the real purchasing power of that growth.
References
Australian Prudential Regulation Authority (APRA), 2026. APRA letter to industry on artificial intelligence (AI), 30 April. Available at: https://www.apra.gov.au/news-and-publications/apra-letter-industry-artificial-intelligence-ai [Accessed 12 August 2026].
Australian Securities and Investments Commission (ASIC), 2026. Open letter to AFS licensees and market participants on artificial intelligence, 8 May (ref. 26-092MR). Available at: https://download.asic.gov.au/media/xhrf1w0e/26-092mr-open-letter-to-afs-licensees-and-market-participants.pdf [Accessed 12 August 2026].
Forrester Research, 2026. Asia Pacific Tech Forecast 2026, press release, 26 March. Available at: https://www.forrester.com/press-newsroom/asia-pacific-tech-forecast-2026 [Accessed 4 August 2026].
GitLab, 2026. AI Accountability Report 2026, June (vendor-published research; sample size not disclosed in the summary reporting available at the time of writing), reported in InfoQ, 2026. AI tools accelerate coding but not overall software delivery, GitLab research finds, June. Available at: https://www.infoq.com/news/2026/06/ai-coding-outpaces-governance/ [Accessed 4 August 2026].
King & Wood Mallesons, 2026. ASIC and APRA issue call to action on artificial intelligence, client insight (detailed legal analysis of the APRA letter of 30 April 2026 and the ASIC letter of 8 May 2026). Available at: https://www.mallesons.com/au/en/insights/latest-thinking/asic-and-apra-issue-call-to-action-on-artificial-intelligence.html [Accessed 4 August 2026].
Monetary Authority of Singapore, 2026. MAS collaborates with banking industry to harness artificial intelligence in the fight against financial crime, media release, 4 May. Available at: https://www.mas.gov.sg/news/media-releases/2026/mas-collaborates-with-banking-industry-to-harness-ai-in-the-fight-against-financial-crime [Accessed 12 August 2026].
Money20/20 Asia, 2026. The Future of Fintech in APAC 2026 (survey of more than 130 senior fintech leaders across Asia), 3 March. Available at: https://asia.money2020.com/program/resources/2026-fintech-trends-report [Accessed 4 August 2026].
Stack Overflow, 2025. 2025 Developer Survey. Available at: https://survey.stackoverflow.co/2025/ [Accessed 4 August 2026].
Stack Overflow, 2026. Mind the gap: closing the AI trust gap for developers, 18 February. Available at: https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap/ [Accessed 4 August 2026].