In financial software, the feature list barely moves the budget. The compliance surface moves it by multiples. Two products that look identical to a user can differ by an order of magnitude in cost because one of them touches money and the other only describes it.
This is the single most useful thing to understand before you scope anything: every regulatory obligation you take on is permanent overhead, not a one-time cost. Audits recur. Evidence must be collected continuously. Architecture decisions you make in month one determine whether that overhead is manageable or crushing.
So the guide starts where the money is, not where the features are.
The First Question: Do You Need to Touch Money at All?
An enormous amount of cost is decided here, and many teams never consciously make the choice.
There is a large difference between software that initiates and holds funds and software that records and instructs while a licensed provider does the moving. The second is a normal software project with elevated security requirements. The first can pull you into money transmission licensing, and that is a business decision with legal and capital consequences, not a technical detail.
Practical guidance we give clients repeatedly:
- Use a licensed provider for movement wherever possible. Payment processors, banking-as-a-service platforms, and payout providers exist precisely so you do not have to become a regulated money business.
- Avoid holding customer funds unless holding them is fundamentally your product. Pooled balances change what you are.
- Get a lawyer's read before architecture, not after. The cheapest version of this conversation happens before anything is built.
If you can design the product so a licensed partner moves the money and your software orchestrates and records, do that. It is usually the difference between a project and an enterprise.
The Compliance Surface, Described Honestly
Which regimes apply depends on what you handle. Each adds distinct, ongoing work:
Two points that save real money. First, scope reduction beats compliance effort — the cheapest way to satisfy PCI DSS is to never let card data reach your infrastructure. Second, retrofitting is far more expensive than building it in. Access control and audit logging added after the fact cost several times what they cost at the start, and the retrofit usually forces rework of things that were already working.
What to Buy and Never Build
We build financial software and there are parts of it we will not build, because buying is strictly better:
- Card processing and storage. Use a processor and tokenization. There is no upside to holding card data.
- Identity verification and sanctions screening. Specialist vendors maintain data sources and detection logic full time.
- Bank connectivity and account aggregation. Buy the service.
- Core accounting. Build the unusual settlement logic if you must; do not rebuild the general ledger — and if the ledger itself is what you are unhappy with, that is an ERP question, not a build question.
- Authentication. Use a managed identity provider with MFA rather than writing your own.
What is genuinely worth building is the layer that expresses your economics — how you price, split, settle, reconcile, and report in ways no product anticipates.
The Ledger Decision That Haunts Projects
If your product tracks balances, obligations, or splits between parties, you need a ledger — and teams routinely discover this after building something that stores a balance as a number in a row and updates it.
That approach fails in a specific and expensive way: when the number is wrong, there is no way to determine why. No history of what changed it, no ability to reconstruct a balance at a point in time, no audit trail an accountant or regulator will accept.
What holds up:
- Record immutable entries; derive balances. Never update a balance in place. Append entries and compute the balance from them.
- Use double-entry structure when value moves between parties. It is centuries old because it makes errors visible rather than silent.
- Make every entry traceable to a cause — the transaction, event, or instruction that produced it.
- Build reconciliation as a feature, not a script. You will compare your records against a provider's daily, forever. Design it deliberately.
- Decide precision and rounding once, explicitly. Rounding disagreements between systems are a recurring source of small, maddening discrepancies.
This is the area where inexperienced teams most often produce something that works in testing and becomes unfixable in production.
Where Financial Software Projects Actually Die
- Compliance discovered late. A customer's security review arrives, and the answer requires re-architecting. Ask your first enterprise prospect what they will require, before you build.
- No reconciliation story. Money is off by a small amount and nobody can explain it. This erodes trust faster than outages.
- Treating exceptions as rare. Failed payments, reversals, chargebacks, partial settlements, and corrections are normal operations, not edge cases. Systems that handle only the happy path push all of it to spreadsheets.
- Underestimating provider integration. Sandbox behaviour and production behaviour differ. Build in time to discover that.
- Building for a licence you do not have yet. Architecture that assumes a regulatory status you are still pursuing is a schedule risk you do not control.
Phase It So Compliance Scales With You
Determine, with legal input, whether you touch funds or instruct a licensed party. Choose providers accordingly. Every later decision inherits from this one, and changing it afterwards means rebuilding rather than adjusting.
Get a single end-to-end flow working on a proper immutable ledger with reconciliation against the provider. Narrow and correct beats broad and approximate — and it is the only way to find out whether your model of the money is right.
Access control, audit logging, evidence collection, and the exception paths — reversals, corrections, partial settlements. Doing this before adding flows means the controls cover everything that follows, rather than being retrofitted across a growing surface.
With the ledger trustworthy and controls in place, additional flows are incremental rather than architectural. This is the point where the project starts feeling fast, and teams that skipped phase 3 never reach it.
Where WorkflowUnity Fits — Honestly
We are a US-based custom software firm building on AWS. In financial software we build the orchestration and ledger layer — the part that expresses your economics — on top of licensed providers who move the money, with access control and audit logging designed in rather than added later.
If you have not yet tested whether a product could serve you, the four gates before building anything custom apply here as much as anywhere. We are not a law firm and we do not advise on licensing; we will tell you to get that opinion before we architect anything. And if your requirement is card processing, identity verification, or bank connectivity, we will point you at vendors rather than build it, because building those is a worse outcome for you.
Frequently Asked Questions
What drives the cost of custom financial software?
The compliance surface, far more than the feature list. Whether you handle card data, verify customer identity for financial services, serve enterprise customers with security review requirements, or hold consumer financial data each adds distinct and ongoing obligations. Two products that look identical to users can differ by an order of magnitude in cost because one touches money directly and the other instructs a licensed provider to move it.
Should my software hold or move customer funds?
Avoid it unless holding funds is fundamentally your product. Software that initiates and holds money can pull you into money transmission licensing, which is a business and capital decision rather than a technical one. Using payment processors, banking-as-a-service platforms, or payout providers to perform the movement while your software orchestrates and records is usually the difference between a normal project and becoming a regulated financial business. Get legal input before architecture, not after.
How should balances be stored in financial software?
Never as a number updated in place. Record immutable entries and derive balances from them, using double-entry structure when value moves between parties, with every entry traceable to the transaction or event that caused it. Storing a mutable balance means that when it is wrong — and it will be — there is no way to reconstruct why, which is unacceptable to auditors and unfixable in production.
What should never be custom built in financial software?
Card processing and storage, identity verification and sanctions screening, bank connectivity and account aggregation, core accounting, and authentication. Each is maintained full time by specialists and each carries regulatory weight you do not want to own. What is worth building is the layer expressing your specific economics — how you price, split, settle, reconcile, and report in ways no product anticipates.
When should compliance work start in a financial software project?
Before the architecture is set. Access control, audit logging, and evidence collection cost several times more to retrofit than to build in, and the retrofit typically forces rework of components that were already working. The most common failure pattern is discovering requirements when a first enterprise customer's security review arrives — ask a prospective enterprise customer what they will require before you build, not after.