Custom software development for finance succeeds when every material transaction can be authorized, processed, reconciled, explained and recovered under the institution's real control environment. Functional demonstrations are insufficient. This checklist connects product scope, financial records, secure development, evidence and operating acceptance. Use it with Edilec's finance software delivery plan, finance software FAQ and custom development checklist.
Approve the financial service boundary
Name the business capability, legal entities, products, users, channels, markets, books and records, upstream and downstream systems, cut-off times and minimum operation during disruption. Identify where money, positions, customer data or regulatory records change. Assign product, operations, finance, risk, security, data and technology owners. Determine applicable obligations with qualified experts; “finance grade” is not a control framework.
Create transaction narratives for initiation, validation, authorization, posting, settlement, reconciliation, correction, reversal and dispute. Include duplicate, late, partial, out-of-order and unauthorized events. State the authoritative record at every step and how identifiers persist across systems. A screen that shows success before durable posting or downstream confirmation can mislead users and corrupt operational decisions.
| Control objective | Design question | Acceptance evidence | Owner |
|---|---|---|---|
| Authorization | Who may initiate and approve? | Role and negative-path tests | Business control owner |
| Integrity | How are duplicates and gaps detected? | Reconciliation under replay | Finance operations |
| Traceability | Can a transaction be reconstructed? | Immutable event and decision trail | Audit owner |
| Resilience | What survives dependency failure? | Recovery and backlog exercise | Service owner |
| Privacy | Which data is necessary? | Flow, retention and access review | Data owner |
Design for controlled change and failure
Document components, trust boundaries, data flows, external services, queues, schedules, keys and privileged paths. Use idempotency, explicit state transitions, durable messaging and reconciliation where the transaction requires them. Define time, precision, rounding and currency rules centrally. Separate ledger facts from projections and display states. The Federal Reserve's interagency third-party risk guidance covers planning, due diligence, contracting, monitoring and termination; use the applicable parts to keep external dependencies inside the service control model.
Design degraded modes deliberately. Decide whether to queue, reject, limit or route work when identity, sanctions screening, market data, payment rails or a core system is unavailable. Prevent an automatic retry from creating duplicate financial effect. Capacity models should include period-end, market events, campaign spikes and recovery backlog. Document recovery point, recovery time and reconciliation objectives in business terms.
Build a secure software delivery system
Apply NIST SP 800-218, the Secure Software Development Framework, across preparation, software protection, production and vulnerability response. Protect repositories, build systems, artifact stores, signing keys and developer endpoints. Require reviewed changes, branch protection, reproducible or attestable builds where practical, dependency inventories, secret scanning and environment separation. Production deployment authority should be limited and attributable.
Translate threat models and obligations into testable requirements. The OWASP ASVS provides a current basis for specifying and verifying application security controls; reference the exact version and requirement identifiers in contracts and test evidence. Cover authentication, session management, access control, validation, cryptography, logging, APIs and configuration according to risk. Automated scanning supports review but does not replace abuse-case and business-logic testing.
Protect financial and customer data
Classify records, define purpose and minimize collection. Enforce role and attribute controls server-side, segregate duties, recertify access and protect break-glass use. Encrypt data and backups with owned key lifecycles. Keep sensitive values out of logs, traces and lower environments. Retention, legal hold, correction and deletion may differ by record type and jurisdiction; implement them from an approved schedule rather than a blanket database policy.
If payment account data is stored, processed or transmitted, determine PCI scope. The PCI standards overview describes PCI DSS and related software standards, and the Council's v4.0.1 notice confirms the current limited revision. Tokenization and hosted payment components can reduce exposure but do not automatically remove every connected system or responsibility.
Test financial behavior, not only code paths
| Test family | Representative case | Required proof | Release blocker |
|---|---|---|---|
| Transaction | Duplicate and out-of-order event | One correct financial effect | Unreconciled difference |
| Authorization | Conflicting and expired role | Denied and audited action | Privilege bypass |
| Precision | Rounding across currency and fee | Approved expected result | Ledger mismatch |
| Resilience | Dependency outage and replay | Bounded backlog and recovery | Data loss or duplication |
| Security | Abuse and tampering attempt | Control prevents or detects | Material open finding |
Maintain traceable requirements-to-tests for unit, contract, integration, migration, performance, accessibility, security, reconciliation, backup and disaster recovery. Use production-scale masked or synthetic data that represents long histories and rare cases. Reconcile counts, values, states and control totals after migration and replay. A test environment that cannot reproduce time-zone, batch or concurrency behavior leaves the most consequential defects for production.
Release through evidence gates
- Approve scope, transaction narratives, obligations, ownership and risk tolerance.
- Baseline architecture, data contracts, control requirements and recovery behavior.
- Build through protected pipelines with versioned artifacts and dependency evidence.
- Pass functional, reconciliation, security, performance and resilience acceptance.
- Rehearse migration, cutover, rollback, communications and support with operators.
- Release gradually and close temporary access, duplicate paths and manual workarounds.
Use dual control for high-consequence cutover steps and retain a timestamped decision log. Freeze criteria should account for financial calendars. Define who can stop, roll back or accept a bounded residual risk. Hypercare needs transaction reconciliation, security monitoring, user support and supplier escalation, not just application uptime. Preserve evidence with the released version.
Operate, audit and exit the service
Monitor user outcomes, SLOs, transaction exceptions, reconciliation breaks, privileged actions, security findings, dependency health and cost. The NIST Cybersecurity Framework connects governance through recovery and can organize an operating profile. Exercise incident response, key compromise, third-party outage, corrupted data and restoration. Verify that recovered services are correct before reopening financial processing.
Contract for source and artifact access, vulnerability handling, notification, subcontractor control, data return, deletion and transition support. Maintain export formats and a replacement runbook. Escrow may help only if materials are current, buildable and legally usable. Test a limited exit before renewal; a contractual right without technical evidence is not an exit capability.
Complete the finance production control review
Before final acceptance, select representative transactions and trace them from user intent to the general ledger or other authoritative record. Include authorization, timestamps, identifiers, messages, postings, fees, reconciliation and notices. Repeat the trace for reversal, correction and dispute. Confirm that support and audit staff can reconstruct events without developer interpretation. Where records disagree, document precedence and remediation rather than choosing the most convenient screen.
Review segregation of duties across code, configuration, data and operations. Identify who can change a calculation, approve a release, alter reference data, assume a privileged role, replay a message or modify a reconciliation exception. Test denied paths and emergency access. Small teams may combine responsibilities, but they need compensating review and evidence. A policy diagram is not proof that technical permissions enforce the intended boundary.
Exercise period-end and stressed operations. Increase transaction concurrency, delay a dependency, cross a daylight-saving or year boundary, exhaust a queue and restore from backup. Verify precision, sequence, cut-off, idempotency and reporting. Reconcile the recovered state with external parties where applicable. Performance testing that reports response time but ignores financial correctness under retry is incomplete.
Inspect the released software bill of materials, dependency findings, build provenance, configuration baseline and open risk decisions. Confirm that vulnerability response can identify affected versions and deploy a tested fix without bypassing controls. Simulate a compromised dependency or signing credential. Suppliers should provide timely evidence and notification, while the institution retains its own inventory and response authority.
Close transitional controls deliberately. Remove migration accounts, elevated vendor access, temporary firewall rules, duplicate feeds and manual spreadsheets or give each an owner and expiry. Verify archive, retention and deletion jobs after production volume arrives. Obtain business, finance, security and operations acceptance separately; one project sign-off should not hide an unresolved control owner.
Review customer and operator communications as controlled outputs. Confirm that confirmations, statements, rejection messages and incident notices reflect the authoritative transaction state and are retained where required. Test duplicate and delayed notifications, inaccessible documents and a communication provider outage. Give users a way to challenge an incorrect result without creating an uncontrolled adjustment. Clear language and accessibility belong in acceptance because a technically correct posting can still create harm when its status or remedy is communicated incorrectly. Reconcile a sample notice to the transaction record before approval, including its delivery status, language version, retained evidence and approved communication template.
- Trace normal and corrected transactions.
- Test segregation and emergency authority.
- Stress correctness across time and retries.
- Inspect build and dependency evidence.
- Close every temporary production control.
Key takeaways
- Map complete financial transactions and authoritative records before coding.
- Build security and change evidence into the delivery system.
- Test duplicate, late, partial, unauthorized and recovery cases.
- Treat reconciliation and degraded operation as product features.
- Accept release and exit through evidence owned by finance and operations.
Frequently asked questions
Should finance teams build or buy?
Compare differentiation, control, integration, skills, time, total cost and exit. Buying still requires configuration, data, access, integration and vendor governance. Building is justified only when ownership and lifecycle capability are credible.
Can regulated finance software use agile delivery?
Yes. Iterative delivery can coexist with segregation, traceability, approval and evidence. Define which changes require which controls, automate repeatable evidence and keep production authority explicit. “Agile” does not waive obligations.
What blocks production release?
Examples include material security findings, unreconciled financial differences, unknown migration loss, untested recovery, missing owners or no safe rollback. The accountable institution should define thresholds before the release meeting.
Conclusion
Custom software development for finance must preserve authorization, integrity, traceability and recovery across change. Model the transaction, build controls into architecture and delivery, test financial failure modes and release only with operating evidence. That discipline produces software that can evolve without making the books, customers or accountable leaders absorb invisible risk.