Every agency has a fintech case study now, because almost every app touches money somewhere. That makes portfolios close to useless as a filter. What does work is a twenty-minute technical conversation with the engineers who would actually do the build — not the account team — built around questions that cannot be answered from a sales script.
Here are the seven I use, and what the answers tell you.
1. How do you represent money?
The correct answers are minor units as integers, or a fixed-scale decimal type, with a reason attached. What you are listening for is whether they have opinions about rounding, about where currency conversion happens, and about how fees are represented relative to the principal amount.
Floating point ends the conversation. It sounds obvious. It still shows up.
2. A payment succeeds at the provider and your service times out before recording it. What happens?
This is the single best question on the list because there is no way to answer it plausibly without having lived through it.
The answer you want includes an idempotency key generated before the outbound call, a persisted intent record written before the request rather than after the response, a reconciliation job that reads the provider's settlement file and closes the gap, and a bounded window with alerting for anything unresolved.
The answer you do not want is any variation on retry logic alone. Retry without idempotency is how duplicate charges happen, and it happens precisely under the network conditions you have no control over.
3. How does a support agent correct a wrong transaction?
If the answer involves updating a row, they have not operated a regulated system.
The correct pattern is a compensating entry: a new record that reverses the effect of the original while leaving the original intact and linked. The original transaction remains queryable forever. The correction has its own actor, timestamp and reason code.
This matters because destructive corrections are invisible in aggregate and catastrophic in an audit. You cannot explain a balance whose history has been edited.
4. Where does the ledger live, and is the balance stored or derived?
There are several defensible architectures — ledger inside the service, ledger as a separate service, ledger as an event-sourced projection. Having no view is not defensible.
The property to insist on is that balances are derivable from immutable double-entry records. Storing a balance as a cache is fine. Storing it as the truth is not, because it means a lost update is silently permanent.
Watch specifically for how they handle the gap between authorisation and capture, and how a currency conversion produces entries. Naive designs fall apart at both.
5. Which parts of PCI scope do you keep, and which do you push out?
The right answer draws a boundary. Tokenising provider or semi-integrated terminal handles card data; your application never sees a PAN; your scope collapses to a much smaller self-assessment.
Teams who cannot draw that boundary on request will discover it during an assessment, at which point moving it is a refactor rather than a design choice.
6. How do you test a risk or fraud model before it goes live, and how do you roll it back?
Baseline answers: shadow deployment where the new model scores traffic without acting, champion-challenger comparison on live traffic, a kill switch that reverts to the previous version or to rules alone, and stored decision records containing inputs and model version so any decision can be replayed.
The follow-up is more revealing: how long would it take, in your architecture, to add a new signal to the fraud model and get it safely into production? If the answer is weeks, then during an actual attack your losses accrue for weeks.
This is also the question that separates AI-as-architecture from AI-as-vendor-logo. Anyone can call a scoring API. Owning the features, versioning the model and being able to explain a decline is engineering, and it is what the LLM integration and applied-AI side of this work actually consists of.
7. What have you had to rebuild on a previous fintech project, and why?
An engineer who has shipped will have an answer immediately, usually with some feeling attached. The most common honest answers are the ledger, the onboarding state machine, and the notification system.
No answer means either not enough shipping, or not enough candour. Both are disqualifying for different reasons.
Why the AI answers matter more than they used to
The operational economics of fintech shifted over the last two years, and it is worth being precise about how. Document review, sanctions alert triage, transaction monitoring and case handling used to scale linearly with headcount. They now scale substantially with compute, provided the system is built so automated decisions carry a stored input, a model version, a confidence score and a defined escalation threshold.
That is an architectural requirement, not a procurement one. A case management layer that treats model output as evidence — with a human adjudicating the flagged minority — is what turns automation into a saving rather than a compliance exposure.
The rest of it
The full write-up covers how to read a fintech portfolio, ledger design in more depth, the four-part cost model, engagement structures and the proposal red flags: How to Choose a Fintech App Development Company in 2026.
Frequently Asked Questions
Should these questions go to the sales team or the engineers?
The engineers who would be assigned to your build, named in the contract. Answers from an account lead are second-hand and tell you nothing about who writes your data layer.
What if an agency answers well but has no fintech portfolio?
Strong answers to questions 2, 3 and 4 are worth more than a portfolio. The failure modes described in those answers only get internalised by teams who have operated systems under real conditions, whether or not the domain was labelled fintech.
Is idempotency really necessary if we use a major payment provider?
Yes. Providers give you the mechanism — idempotency keys — but nothing enforces that you use it correctly, and the failure happens on your side of the call when a response is lost. The provider's reliability does not cover your write path.
How do we verify a claimed audit trail?
Ask to see a query that answers a concrete question: who accessed a specific customer record on a given date, and what changed. If the answer requires log grepping rather than a queryable event store, the audit trail is aspirational.
Do we need our own ledger if the payment provider tracks balances?
Yes. The provider records movement through their system, not your fees, holds, splits or accounting treatment. More importantly, with only one record you cannot reconcile — a discrepancy is undetectable by definition.
How much does the ledger design actually cost upfront?
Typically a few weeks of senior engineering time in the first phase. The alternative is a four-to-six month rebuild later, run in parallel with production, reconstructing history from settlement files. The ratio is not close.
Top comments (0)