Banking & Finance

A balance is not a column updated on a user row; it is a value derived from immutable movement records. With a column, concurrent operations overwrite each other, a faulty update cannot be undone, and "why is this balance what it is?" has no answer. The architecture is detailed in our fintech ledger guide.

• Double-entry ledger: every transaction producing at least two lines summing to zero, with corrections made by reversing entries rather than deletion.
• Monetary precision: amounts stored as integers in the smallest unit, with the rounding rule defined in one place.
• Retry protection: a repeated request after a network timeout must not create a second transaction.
• State machine: initiated → authorised → captured → refunded or charged back, with permitted predecessor states declared.
• Reconciliation: daily comparison of your ledger against the provider or bank file, monitoring the age of unresolved items.
• Authorisation and logging: immutably storing who performed which operation under which authority and what value changed.

Payment, wallet and application processes use fintech software, statements and collection matching use bank integration, liquidity management uses cash flow tracking, and customer processes use CRM. The internal integration layer falls under API and system integration.

The most effective security decision is not to store card data at all. With a provider-hosted field or on-device tokenisation, sensitive data never passes through your system and the compliance scope narrows considerably. This is an architectural choice rather than a certification claim; the final assessment follows the requirements of the relevant standard and its assessment process.

On the finance side the starting point is usually this: collections arrive from the bank, are posted to accounting by hand, and the customer account is updated on yet another screen. Differences between the three surface at month end and are reconciled manually.

The first exercise produces an end-to-end map of money movement: which channel money enters through, what identity it carries (statement description, reference number, virtual POS transaction code) and which record it must match. Without a defined matching key, automatic reconciliation cannot be built.

• Double-entry ledger: a debit and a credit line per movement; a single-line balance update is not auditable.
• Idempotency key: a unique key that prevents a resubmitted transaction from being processed twice.
• Matching key: the reference that determines which invoice or account movement a collection settles; a description string alone is insufficient.
• Transaction state: pending, successful, failed and cancelled held separately; "failed" and "no response received" are not the same thing.
• Commission and deductions: bank commission, holds and value-date differences recorded as separate lines.
• Currency and rate: transaction currency, booking currency, and the source and date of the rate used.

1. Ledger and identity: chart of accounts, double-entry structure, transaction states and the idempotency rule.
2. Bank connection: statement retrieval, description parsing and matching rules.
3. Payment channels: virtual POS, instalments, refunds and partial refunds.
4. Reconciliation and reporting: automatic reconciliation, difference lists, commission checks and cash projection.

• Share of collections matched automatically and the number of records needing manual intervention
• Reconciliation differences by type (ours not theirs, amount mismatch, commission)
• Number of transactions left in a "no response received" state and how long they take to resolve
• Amounts held pending due to value dates and blocks
• Receivable ageing by due date

• Updating a balance in a single field. Without movement history there is no variance analysis and no audit trail.
• Skipping idempotency keys. A retried request after a network fault produces duplicate records.
• Treating an unanswered call as a failure. A transaction that succeeded on the other side appears cancelled on ours.
• Burying commission inside the collection amount. The customer account closes short and the customer sees a wrong balance.

Is deriving balances from movements slow?

Periodic closing balances are kept and the query only adds movements since the last close, preserving both speed and traceability.

What if a transaction must be deleted?

It is not deleted; a reversing entry is created and linked to the original. Altering history in financial records destroys auditability.

How are reconciliation differences classified?

In three groups: present in yours but not theirs (an operation whose response was lost), present in theirs but not yours (a missed notification), and present in both with different amounts (commission, rounding, currency). Each has its own resolution path; see the bank integration guide.

Which bank integration method should be preferred?

It depends on the bank: a direct API, file-based transfer (MT940 and similar), or scheduled export from corporate online banking. APIs give the fastest feedback; file-based methods are more widely supported. The choice follows the channel the bank offers and the latency tolerance required.

What needs care in virtual POS refunds?

Partial refunds, refunds of instalment transactions and same-day versus later refunds all behave differently. Every refund must be linked to the original transaction reference and carry its own state flow; recording a refund as a negative sale breaks reconciliation.

How far ahead can a cash projection run?

For contracted collections and payments the due dates are known, so the projection is calculated directly. Estimated items belong in a separate scenario layer, and the report must visibly separate actual from estimated; when the two blend, the projection stops driving decisions.