The demo goes well. The business stakeholder is convinced, the pilot scope is agreed, and commercial terms are close. Then the bank's vendor risk team sends over its due diligence questionnaire. Somewhere in the information security section, there is a block of questions about regulations that will not apply for another year.
The deal then goes quiet. Nobody says why.
Before moving into RegTech, I worked at one of the top ten banks in Bulgaria. I have been on both sides of that conversation. From the vendor side, the buyer is asking too early. From the bank side, the vendor is answering too late. Both are right, and that gap is where deals fail.
This is quite a frustrating dynamic to watch, especially when the product is genuinely good and the timing was almost right. In this article, I’ll walk through why deals fail on compliance readiness before the deadline even arrives, and what RegTech vendors can do about it.
The deadline your customer is actually working to
Take the AMLR as an example. It applies from July 2027. A bank that needs a new screening and monitoring stack by then is looking at 12 to 18 months of implementation, integration, and testing. That puts vendor selection now. The due diligence question is not early. It is on time for their schedule.
The AI Act follows the same logic. The Digital Omnibus moved high-risk obligations for Annex III systems to December 2027. The extra 16 months gave vendors more time to build. It did not change what buyers need to verify before signing.
Read article: EU AI Act: What It Is, Deadlines and How to Prepare in 2026
There is also a structural reason buyers ask earlier than they used to. Since January 2025, DORA has required EU financial entities to assess ICT providers before signing, keep a register of every contract, and include specific clauses. Every new vendor relationship is now a compliance event in its own right.
A contract signed this quarter will likely still be running when the AMLR, the AI Act, and the Cyber Resilience Act all apply. The bank is not buying your product as it exists today. It is buying the next three to five years of it.
Some obligations are already here. The CRA's reporting duties for software manufacturers applied from September 2026. If your product is in scope, a buyer asking about your vulnerability reporting process is not asking about the future.
What the questions actually sound like
Buyers rarely ask directly "Are you compliant with X?"
Instead, they’ll ask you to show them something. Across the questionnaires we see, each regulation turns into a small set of very concrete requests:
Look at the right-hand column. None of it is a statement of intent. Every item is an artefact that either exists today or does not. That is the real test, and it is a very different test from the one most product roadmaps are built for.
Roadmap-ready is not the same as evidence-ready
When a vendor answers a compliance question with a roadmap date, it feels like a reasonable answer. On the buyer's side, it reads very differently.
A vendor risk team cannot score a roadmap. Their own supervisors will ask how they assessed your product, and "the vendor said it is planned" does not hold up in that conversation. So a roadmap answer is not marked as partial. It is marked as a risk. Risks need an owner, a mitigation plan, and often a sign-off from someone senior who has no reason to take on yours.
This is also where the cost hides. A deal that fails in vendor risk rarely shows up in the CRM as lost to compliance. It shows up as "no decision", "timing" or "budget moved". Sales teams feel it long before product teams see it in any report.
There is a second cost, and I think it is the bigger one. When compliance lives on the roadmap, it competes with features for capacity and usually loses until a deadline forces it. Then it arrives as one rushed programme that touches the data model, the audit trail and the logging layer at the same time. Those are exactly the places where rework is most expensive. When I wrote a diagnostic for AMLR readiness this summer, almost every question came down to architecture rather than features. The same is true here.
The vendors who handle this well do something simple. They separate what the law requires by a certain date from what a buyer needs to see today, and they build the second one first. In practice, that means evidence: documentation, a demonstrable audit trail, a named owner for incident reporting. Full compliance can follow on the legal timeline. Proof of direction cannot wait for it.
Six questions to ask before your next vendor review
If you lead а product or partnerships at a company selling into regulated industries, these are worth working through now.
- Which regulations bind your customers? DORA does not apply to most software vendors directly, but it shapes every contract they sign with a bank. Map your buyers' obligations first, then work out which ones flow down to you.
- What did you answer "planned" to in your last three questionnaires? Pull them out and count. That list is your real compliance backlog, already prioritised by the people who pay you.
- Who owns compliance evidence across product, engineering and sales? In many teams, answers are written by whoever is available that week. Inconsistent answers across deals become contractual exposure later.
- Can you demonstrate, or only describe? Take one requirement and try to show it live without pulling in engineering. If you cannot, that is the first thing to fix.
- Does your roadmap separate evidence work from compliance work? Evidence items like a classification rationale or a documented exit plan are small and can ship this quarter. Architecture changes can follow the legal timeline, but only if the evidence is already there.
- Is your delivery chain covered? Under DORA's subcontracting rules, buyers look past you to the partners behind your service. If an external team works on your product, their evidence is part of yours.
Compliance is a product capability now
The legal deadline still matters. It is when supervisors can act and when fines become possible. But for anyone selling into a regulated industry, it is no longer the date that decides whether you win the deal.
The same dynamic appears outside financial services. In aviation, EASA's Part-IS information security rules became fully applicable in February 2026. Air operators and maintenance organisations have to manage information security risk that reaches them through their suppliers, so the questions land on vendors' desks too. Different regulator, same pattern.
The teams that handle this well treat compliance the way they treat performance or security: as a product capability that can be demonstrated on request, not a project staffed when the deadline gets close. Build the evidence first, keep it current, and give your sales team something they can show rather than promise.
If your next questionnaire arrives tomorrow, the question is not whether you will be compliant by the deadline. It is whether you can show, today, that you are on the way.
At Dreamix, we work with RegTech, fintech and aviation product teams on this kind of readiness work, from mapping evidence gaps to building the audit trails and reporting flows that buyers ask to see. If you would like a second pair of eyes before your next vendor review, get in touch.
