Custom treasury management software development
Appfront builds bespoke treasury software for organisations that cannot see their cash position in one place: multiple entities, multiple banks and sometimes multiple currencies. We usually don't build the complete treasury package but the layer around it: a consolidated view across systems that don't know about each other, a forecast tailored to your operations, and a payment process in which segregation of duties is enforced. If a standard package fits better, we will say so.
The problem is rarely money, it is visibility
Treasury management concerns an organisation's money and financial risks: the liquidity position across all accounts and entities, the forecast of incoming and outgoing flows, payment traffic, and managing currency and interest rate risk.
The constraint is rarely the balance in the account, but the moment that balance becomes known. Anyone holding seven accounts with three banks only learns the previous day's position the next morning, because the daily statement is delivered overnight. As long as that is the case, you cannot steer; you can only establish what happened after the fact. The picture is always the same: at one entity cash sits idle while another, in the same week, is drawing on its overdraft facility and paying interest on it. This is not a financing problem but an information problem.
This page is about your own money: positions, forecasting, payments and risk. If the matter is accepting customer payments and transaction reconciliation, you are more likely to need a payment platform. The two meet at reconciliation, but the supervisory framework differs fundamentally.
One position, all accounts
Balances and bookings from every bank in the same structure, with the age of the data visible per account. If you don't know the hour, it is an estimate.
A forecast you can check
A forecast only improves once variances against actual results are fed back into it. Without that loop, the input stays just as rough year after year.
Paying with control
Whoever prepares a payment should not also approve it. That four-eyes principle belongs in the software, not in the procedures manual.
What goes wrong in practice
Four situations we encounter on almost every treasury project. If none of them sound familiar, your setup is probably sufficient.
The morning position is already out of date
Yesterday's end-of-day statement arrives overnight. By nine o'clock, you therefore know the position as it stood before the salary run and before the large supplier batch. If you want to steer the day, you need intraday reporting, which is usually a separate banking service that not every bank offers to every subsidiary. That is why we show, per account, how current the data is.
A forecast nobody checks
The forecast comes from a spreadsheet for each entity, with different cut-off dates, different assumptions about debtor payment behaviour and a controller who deliberately keeps his figure cautious. The variance against actuals never flows back to the person who prepared it. A model only improves when it corrects itself based on historical payment patterns per debtor and per season. A predictive analytics dashboard delivers more there than an extra column would.
The account number that quietly changed
A supplier emails a new bank account number, with a plausible reason and an existing file reference. Accounts payable updates the record. Weeks later, a perfectly routine payment goes to an account that does not belong to that supplier. The vulnerability lies not in the payment moment but in the change moment, and that change is often made without a second pair of eyes.
The intercompany balance nobody can explain
As soon as entities settle amounts between themselves, an in-house bank effectively emerges: the holding company maintains the external banking relationship, while the subsidiaries receive an internal current account. This concentrates liquidity, but administratively it is stubborn. Each entity has its own general ledger and not infrequently its own ERP, currency conversion takes place on different rate dates, interest must be charged on an arm's-length basis, and at quarter-end a difference remains that nobody can trace. A netting model that records the exchange rate, interest rate and counter-entry for each movement is usually where custom development delivers the most value.
The integrations where projects really get stuck
Treasury software stands or falls on its connection to the bank, and that runs on standards you don't set yourself. Account information and payment instructions travel via the ISO 20022 messaging standard, which, according to Betaalvereniging Nederland (the Dutch Payments Association), is the international standard for digital data exchange in payments. SWIFT has used it for all messages between financial institutions since the end of 2025.
Two messages do most of the work. The end-of-day statement arrives as camt.053, the Bank to Customer Statement. According to Betaalvereniging Nederland, it succeeds the older MT940 message and carries richer, better-structured data. Payment instructions go the other way as pain.001, the SEPA Credit Transfer Initiation, with pain.008 for direct debits and pain.002 as the status feedback listing rejected items. Within those standards, banks make their own implementation choices: the same field is populated differently, legacy systems still require MT940, and a foreign subsidiary delivers yet another variant. Plan for mapping per banking relationship and for maintenance whenever the format changes.
Retrieving account information via PSD2 can be a good route, but it requires a licence. Under the Dutch Financial Supervision Act (Wet op het financieel toezicht), an account information service is a payment service, and Article 2:3a prohibits carrying on the business of a payment service provider without a licence from De Nederlandsche Bank. We do not hold one. PSD2 integrations therefore run through a licensed provider: a deliberate choice, with its own costs and its own dependency.
Since October 2025, the Instant Payments Regulation requires banks to verify the payee: the recipient's bank checks the account name against the IBAN and reports back whether it is a match, a close match, no match or unverifiable. For your system, that means an additional outcome to display, record and be able to override.
Whoever prepares, does not approve
Segregation of duties is not bureaucratic red tape but the most important control you have: whoever prepares a payment or batch must not be able to release it themselves. In the regular payment run, this is rarely broken. It goes wrong in exceptions: the urgent payment on Friday afternoon, the holiday period in which one person ends up with both roles, or the administrator account that happens to be able to approve as well.
Software can close those exceptions in a way a procedure cannot. Roles attach to functions rather than individuals, a second role on the same account does not count as a second pair of eyes, and an urgent procedure does not lower the threshold but records additional oversight.
Fraud involving a changed supplier bank account follows the same logic one step earlier: treat a change to the creditor master data as a separate action with its own approval, store the outcome of the payee check alongside the payment instruction, and flag a first payment to a new IBAN as an exception. If you operate in a regulated sector, DORA compliance software fits in with this.
- Four-eyes principle on every outgoing batch, including urgent payments
- Preparing and approving separated into roles, not individuals
- Authorisation limits by amount, currency and counterparty account
- Changes to creditor IBANs handled as a separate process requiring approval
- Outcome of the payee check recorded alongside the payment instruction
- First payment to a new IBAN treated as a deliberate exception
- Audit log that cannot be altered after the fact
- Bank status feedback automatically reconciled
- Administrative rights kept separate from payment rights
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →When you shouldn't have this built by us
Mature treasury packages exist: Kyriba, Nomentia and TIS, plus the treasury modules of the major ERP vendors. For an organisation with a conventional structure, a handful of entities, one or two banking relationships and the euro as its base currency, such a package is almost always the better choice. The reason is not functionality but infrastructure: the bank integrations are already in place, the format differences between banks have been absorbed, key management is set up, and the security around payment instructions is well developed, and all of that is maintained when a standard changes. Rebuilding it costs a lot and gives you nothing distinctive.
Custom development pays off in a limited number of situations. The first is the layer on top: a consolidated view across systems that do not know about each other, for example three ERPs inherited from acquisitions plus a project accounting system, where the problem is not the package but the origin of the data. The second is a forecasting model in which project phases or contractual milestones drive cash flow in a way a standard model does not account for. The third is a structure packages do not anticipate, such as companies that are formed and dissolved per project.
Weigh up what you take on. Once you create payment instructions yourself and maintain secure bank connections, the management of certificates, keys and access rights falls to you, including the question of who takes over if the person who set it up leaves. If you are a financial entity, a self-built system falls under DORA, Regulation (EU) 2022/2554, applicable since 17 January 2025. Often the sensible outcome is a combination: the package handles the bank integration and payment execution, while custom software provides the overview and the model.
Frequently asked questions about custom treasury software
The questions people ask just before signing, including the awkward ones.
Often you have to. Packages such as Kyriba, Nomentia and TIS, and the treasury modules of the major ERP vendors, have already set up and maintain the bank integrations, key management and security around payment instructions. For a handful of entities, one or two banks and the euro as base currency, a package is almost always better. Custom software only pays off when you structurally need something the package doesn't do.
Not in your own name. Under the Dutch Financial Supervision Act (Wft), an account information service counts as a payment service, and Article 2:3a prohibits carrying on the business of a payment service provider without a licence from De Nederlandsche Bank. We do not hold that licence. We therefore connect through a party that does, or we retrieve the data through your bank's business channel using camt messages.
By enforcing segregation of duties in the software rather than describing it in a procedure. Whoever prepares a batch cannot approve it themselves, not even with an urgent status and not via a second role on the same account. In addition, authorisation limits apply per amount, currency and counterparty account, and an audit log records every step irreversibly.
Partly, and it is more honest to name the limit. Since October 2025, the Instant Payments Regulation requires banks to verify the payee: the recipient's bank checks the account holder name against the IBAN and reports back whether it matches, nearly matches, does not match, or cannot be checked. That helps with the transfer. The fraud usually starts earlier, with the change in your creditors file, and that is exactly where we impose approval and logging.
The source code, documentation and infrastructure definitions belong to you, recorded in the contract and held in a repository to which you have access yourself. We build on widely used technology so that another party can take over. Make sure these arrangements are explicitly agreed with every supplier before you sign, including with us.
Your accountant needs to establish that payments only arise through an approved route. That requires an audit log showing, for each payment, who created it, who approved it and what status the bank reported; reconciliation between what the system sent and what the bank statement shows; and a documented authorisation model. If you are a financial entity, the DORA obligations come on top of that.
Related services
Three adjacent topics. If your question sits closer to one of these, start there.
Building a payment platform
Not your own cash position, but accepting customer payments, paying out to connected parties and reconciling transactions.
Predictive analytics dashboard
If the core lies in the quality of the forecast, that is more a predictive model than a treasury system.
DORA compliance software
If you are a financial entity, self-building brings registration and testing obligations.
First, find out whether you should build this at all
Tell us how many entities and bank relationships you have, how your current position comes together, and where it hurts: the timeliness of your figures, the forecast, the payment process, or intercompany netting. We'll also tell you when a standard package is the better choice.