Core Banking System Development

The account ledger is a double-entry posting engine that records every financial event as a debit and credit pair. Every transaction -- a deposit, a withdrawal, a fee charge, an interest accrual -- generates a posting entry that maps from the product account to the general ledger account code. Transaction reference and payment narrative are stored against every entry so the audit trail is complete at the ledger level, not reconstructed from application logs. Posting date and value date are handled as separate fields because the date a payment is received and the date it becomes available to the customer are not always the same. Reversal and correction workflow allows a posted transaction to be unwound with a compensating entry rather than deleted, preserving the integrity of the ledger history. Balance sheet and profit and loss position can be calculated from the ledger at any point in time by summing posted entries -- the ledger is the source of truth for every financial position.

Daily accrual calculation runs across all savings, deposit, and loan accounts, accumulating interest earned or owed in an accrual balance that posts to the customer account on the configured cycle. Rate structure configuration supports the full range of product designs -- fixed rate, variable rate linked to a base rate index, tiered rate by account balance, introductory rate for a defined period before reverting to the standard rate -- each configured per product type in the admin interface rather than hardcoded into the engine. Interest posts on the cycle defined for each product -- monthly, quarterly, annual -- and the engine supports both simple and compound interest per your product rules. Penalty interest calculation for loan arrears applies the default rate from the date a payment is missed, with the rate differential between the contractual rate and the default rate accruing separately for reporting clarity. Rate change effective date management ensures that when a variable rate changes, all historical periods continue to be calculated at the rate that applied on each date, and the new rate applies only from the effective date forward.

Account product types are configured through an admin interface rather than code changes, which means your product team can launch a new savings account or adjust fee schedules without a software release. Supported product categories include savings accounts, current accounts, fixed deposit accounts, notice accounts, and loan products, each with its own configuration schema covering rate structure, fee schedule, minimum balance, and term rules. Fee schedule configuration is per product and covers monthly maintenance fee, transaction fee, overdraft fee, minimum balance fee, and any custom fee types specific to your product range. Product eligibility rules define which customer types can open each product -- individual, joint, corporate, trust -- with eligibility checked during account opening workflow. Account opening and closure rules specify the steps and document requirements for each product. Dormancy and reactivation policy is set per product type, defining the inactivity period that triggers dormancy status and the process to reactivate without manual intervention from the operations team.

The customer record holds identity data, KYC status, and the full list of accounts and products the customer holds with the institution. Account opening workflow moves an application from submission through KYC approval to active account status, with each step logged and the decision reason recorded against the customer record. Multi-account customer view shows all products held -- savings, current, fixed deposit, loan -- with current balance and status in a single view for branch staff or internal operations teams. Account status management covers the full lifecycle -- active, dormant, restricted, and closed -- with status changes logged and reversible under the appropriate workflow. Joint account ownership is handled with configurable authorisation rules per signatory type, so a joint account can require both signatories for payments above a threshold or either signatory for day-to-day transactions. Corporate customer hierarchy handles subsidiary account management, connecting a parent entity to its subsidiary entities and their respective accounts under a single corporate customer profile.

Regulatory reporting outputs are generated from the ledger data and formatted to your specific regulator's requirements rather than produced as generic exports that require manual reformatting. Supported report types include FDIC call reports for US insured institutions, FCA regulatory returns for UK-regulated firms, Basel III capital adequacy calculations, CCAR stress testing data submissions, AML transaction reports to FinCEN or equivalent, and interest reporting to tax authorities for customer income reporting obligations. Report schedules are configured with automated generation and delivery to the appropriate submission channel, so the compliance team is not manually running reports at period end. Every report generated is logged with the generation timestamp, the data period it covers, and the submission outcome, creating an audit trail of regulatory submissions. Data lineage traces from each line item in a report back to the source transactions and ledger entries that contributed to it, which is the record a regulator asks for when they question a submission figure.

A REST API exposes account balances, transaction history, and payment initiation to digital banking front ends, allowing the customer-facing app to read from and write to the core without direct database access. Core-to-switch integration handles card transaction posting, receiving authorisation and settlement messages from the card switch and posting them to the account ledger with the correct value date and merchant narrative. Payment rail integration connects the core to ACH for US dollar payments, SWIFT for international wire transfers, Faster Payments for UK domestic transfers, and SEPA for Euro-area payments, with the integration layer handling message formatting and acknowledgement for each rail. Reconciliation between the core ledger and each payment rail runs automatically, matching every outbound payment instruction to a confirmed settlement and flagging any discrepancy for the operations team before it becomes an unreconciled difference. Third-party service connections for credit bureau enquiries, sanctions screening, and document management are built as discrete integration modules so each service can be swapped without reworking the core data model.