Which of the four systems should we start with?
Start where money is currently unexplainable. If balances or settlement cannot be reconciled, the payment or lending accounting core comes first regardless of what the roadmap says, because every later feature inherits that uncertainty. If the numbers are sound and the problem is customer experience or operations effort, then onboarding, the client portal, or the back office console will return more. We will tell you which case you are in after looking at your data, and we have advised prospective clients to fix accounting before building the product they came to ask for.
Is AgileTech licensed or certified for financial services?
No, and this matters enough to state on every page. We hold ISO 9001:2015 and ISO 27001:2013 and no financial services licence, permission, or certification of any kind. We are not a bank, payment institution, lender, or adviser. We are not PCI DSS certified as an entity. We do not hold client funds and we are not party to your regulatory permissions. Those obligations are yours, and we build to whatever they require.
Do you have fintech case studies we can see?
We have two published case studies with client permission, both in hospitality rather than fintech, and you will find them in our portfolio. We will not present anonymised financial metrics or unnamed client claims as evidence, because unverifiable figures are worth nothing to you when assessing a vendor. What we can do is walk through our approach against your actual data model and let you judge the engineering directly, which is a more useful basis for a decision anyway.
Why do you insist on double entry ledgers?
Because a balance you store and edit cannot be audited. If a balance is one number that gets updated and it turns out wrong, there is no way to determine when or why. With immutable double entry, the balance is the sum of its entries, every entry has a cause, and a discrepancy points to a specific movement on a specific date. Corrections post as reversing entries, so history is never rewritten. It costs slightly more at the start and saves a great deal later.
How do you prevent duplicate charges and double postings?
Idempotency keys enforced at the platform boundary on every money moving operation. A repeated request with the same key returns the original result rather than acting again. This covers the ordinary causes: a user tapping twice, a mobile client retrying after a timeout, a queue redelivering a message, and a batch job rerun after a failure. Provider level idempotency is used where offered, but never relied on alone.
Can you work with our existing system rather than replacing it?
Usually, and it is often the better sequence. A frequent engagement is leaving the working acceptance or origination path in place while we build the ledger, reconciliation, and reporting layer that was never finished, then migrating the rest behind a stable interface. This puts effort where the loss actually is. Full replacement is sometimes correct, but it should be a decision rather than a default.
How do you handle regulatory requirements you are not qualified to interpret?
We ask your compliance function or external advisers to specify the requirement, and we implement and evidence it. We do not interpret regulation for you and we will not pretend to. What we do bring is knowledge of what these requirements usually imply for software: effective dating, immutability, reproducibility, segregation of duties, retention, and reporting. Raising those early is where we add value; advising on the regulation itself is not our role.
What technologies do you use for financial systems?
Strictly typed languages on the money path, typically Java, Kotlin, or Go, because they eliminate whole classes of arithmetic and null error. PostgreSQL as the system of record with exact numeric types, append only ledger tables, and strong constraints. Python where modelling sits close to your own analytical work. The choices are deliberately conservative, because a financial platform outlives the team that builds it and must be maintainable by people we will never meet.
How long does a fintech platform take to build?
A focused platform with one provider or core, one currency, and a proper ledger and reconciliation is typically several months. Multiple providers, currencies, products, or markets extend that considerably, and the extension is mostly in reconciliation and edge cases rather than in the visible flows. We give a range after mapping the money and testing your interfaces, because an estimate before those two steps is guesswork presented as a number.
Who owns the code, the data, and the provider relationships?
You own all three. Source code, infrastructure definitions, and documentation are delivered into your repositories as we go rather than at the end. Provider and custodian contracts are between you and them, so no funds or commercial relationship route through us. We build for handover on the assumption that your own team or another vendor maintains the platform without us.
What do you need from us to begin?
The movements your system must support, your licence position, the providers or core you use with sandbox access, your expected and peak volumes, and whether an existing book or ledger will migrate. If a system already exists, a data extract and one recent settlement or statement file tells us more in an hour than a week of workshops, because it shows us what is actually happening rather than what is believed to be.
