Industries / Banking, financial services & insurance
Financial systems where the numbers have to reconcile
We build the transactional core of financial businesses: lending origination and decisioning, KYC and AML workflow, payment integration across UPI, SEPA, ACH and Faster Payments, double-entry ledgers, reconciliation engines, regulatory reporting and insurance policy administration. Designed for auditability first, because in BFSI a system that cannot explain a number is a system that will be replaced.
- Append-only ledgers with idempotent posting and derived balances
- PCI DSS scope minimised by tokenisation before design begins
- Reconciliation treated as a first-class product, not a batch job
- We are not a regulated entity and give no regulatory advice
At a glance
- Payment rails
- UPI and NPCI, SEPA and SCT Inst, ACH, Faster Payments, card acquiring
- Messaging
- ISO 20022, ISO 8583, legacy MT coexistence
- Regulatory context
- RBI, FCA and PRA, PCI DSS v4.0, PSD2 and SCA
- Ledger model
- Append-only double entry, derived balances
- Screening
- Sanctions, PEP and adverse media via licensed providers
- Availability target
- 99.95% on supported architectures
- Enquiries
- nitesh@redcubical.com
Foundations
Double-entry ledger design, and the three rules we do not bend
How we design a financial ledger
A ledger is an append-only journal of balanced double entries. Balances are derived, never stored as a mutable field. Every posting carries an idempotency key so a retried request cannot duplicate money. Corrections are reversing entries, not updates. These three rules cost a little performance and save every dispute investigation you will ever run.
The non-negotiables
- Immutability. No UPDATE and no DELETE against journal rows, enforced by database permissions rather than convention. A mistake becomes a reversal plus a new entry, so the history of the error survives.
- Idempotency. Every posting request carries a client-supplied key. The key, the resulting entry identifier and the response are stored together, so a duplicate request returns the original result instead of moving money twice. Gateways retry; networks partition; this is not hypothetical.
- Atomic balance. Debits equal credits within one transaction, checked in the database, not in application code that a future refactor might bypass.
Practical structure
- Accounts with type, currency and a normal balance direction. Suspense, clearing and fee accounts modelled explicitly rather than improvised later.
- Journals grouping entries into an event with a business reference, so a refund reads as one thing rather than four rows.
- Effective date separate from posting date, because backdated corrections are normal and reporting periods close.
- Minor units as integers. No floating point anywhere near an amount, and currency stored with every amount.
- Materialised balances as a cache with a recompute job that proves the cache matches the journal.
Eventual consistency and money
Distributed systems advice that is sound for a product catalogue is dangerous on a posting path. Our position:
- The ledger write is one atomic transaction in one database. Not a two-phase commit across services, and not a best-effort sequence of API calls.
- Cross-service effects use a transactional outbox. The event is written in the same transaction as the entry and published afterwards by a relay, so an event cannot exist without its entry or vice versa.
- Consumers are idempotent and ordered per account. Partition by account so replays cannot interleave into a wrong balance.
- Sagas need real compensations. A compensating entry that reverses a transfer is legitimate; deleting the original is not.
- Read models may lag, and the interface must say so. Showing a stale balance as if it were authoritative is how customers overdraw and support queues fill.
- Reservation before capture. Authorisations, holds and pending entries modelled as first-class states rather than inferred from timing.
The failure mode we see most often is a microservice architecture where three services each hold part of the truth about a balance and none can be reconciled against a bank statement.
Payments
Payment rails and what each one demands of your system
Rails differ in settlement speed, reversibility, message format and failure semantics. Those four properties, not the API documentation, determine your architecture.
How to think about a payment rail
The design questions per rail are always the same: is settlement real-time or batched, is the payment reversible and for how long, what identifies a transaction uniquely, and how do you learn about a failure. Instant, irrevocable rails such as UPI and SCT Inst push validation before submission. Reversible batch rails such as ACH push effort into returns handling and provisional balances.
| Rail | Geography and use | Settlement and reversibility | What it demands of your build |
|---|---|---|---|
| UPI (via NPCI) | India, person-to-person and person-to-merchant, collect and pay, mandates for recurring | Near-instant, effectively irrevocable. Disputes handled as a separate chargeback-style process | Sponsor bank or licensed provider relationship. Idempotent handling of duplicate callbacks, deterministic transaction reference generation, mandate lifecycle for autopay, and settlement reconciliation against the bank file rather than the callback |
| Other NPCI rails: IMPS, NEFT, RTGS, AePS, NACH | India, account transfers, bulk mandates and high-value settlement | IMPS near-instant, NEFT batched, RTGS real-time gross for high value, NACH mandate-driven debits | Cut-off time awareness in scheduling, mandate registration and amendment flows, return code mapping to customer-facing reasons, and holiday calendars in the settlement model |
| SEPA Credit Transfer and SCT Inst | Euro area credit transfers and instant payments | SCT batched with next-day style settlement; SCT Inst within seconds and irrevocable | IBAN validation and structured party data, ISO 20022 pacs messages, end-to-end identification discipline, and Verification of Payee style name checking where mandated |
| SEPA Direct Debit | Euro area recurring collections, Core and B2B schemes | Collected on a due date with refund rights extending well beyond settlement for Core | Mandate storage with unique reference and proof, pre-notification timing, R-transaction handling for returns, refunds and reversals, and provisional balance treatment until the refund window passes |
| ACH (US) | United States credit and debit batch payments | Batched with same-day options. Returns and administrative returns arrive days later | Return code handling as a core workflow, not an edge case. Provisional posting with clear customer messaging, retry rules per scheme, and NOC handling for account detail changes |
| Faster Payments and Bacs (UK) | United Kingdom instant payments and batch collections | Faster Payments within seconds; Bacs on a three-day cycle | Confirmation of Payee checks, sort code and account validation, APP fraud controls and warnings, and reconciliation across both rails into one ledger view |
| Card acquiring | Global, online and card-present | Authorisation then capture then settlement, with chargeback rights months later | Tokenisation so no primary account number is stored, 3-D Secure and SCA exemption logic, authorisation-to-capture state machine, partial capture and refund handling, and a chargeback lifecycle with evidence collection |
| ISO 20022 migration | Cross-border and high-value messaging replacing legacy MT | Not a rail but the message standard the rails are moving to | Richer structured data to populate, longer field handling, structured addresses and party identification, truncation rules during coexistence, and dual reconciliation while both formats are live |
Two rules regardless of rail. First, the callback is a hint and the settlement file is the truth, so reconcile against the file. Second, generate your own idempotent transaction reference before you call the provider, because a timeout with no response is the case where a missing reference costs you a duplicate payment.
Reconciliation
Why reconciliation engines are harder than they look
What a reconciliation engine really is
Matching is the easy 20 percent. The hard 80 percent is explaining and routing differences: many-to-many matches, fees netted at source, timing across settlement cycles, currency conversion, duplicates, reversals, partial refunds and clearing-account movements. A reconciliation engine is really an exception-management product with a matcher attached, and it should be scoped that way.
| Break type | Typical cause | How the engine should handle it | Who resolves it |
|---|---|---|---|
| Timing difference | Transaction captured before the cut-off but settled in the next cycle | Age the break and auto-clear when the matching side arrives within the expected window. Only escalate on window breach | No human, unless aged beyond tolerance |
| Fee and net settlement difference | Provider settles net of fees while the ledger recorded gross | Normalise both sides to gross plus a fee entry using the provider fee schedule, then match on gross | Finance, only when the fee schedule changes |
| Duplicate in source | Provider file contains the same transaction twice, or a retried request created two payments | Deduplicate on provider reference plus amount plus timestamp window. Flag genuine duplicate payments as a money-impacting break | Operations, with a defined refund path |
| Reversal or chargeback | Refund, return or dispute arriving days or months later | Link to the original entry, post a reversing entry, and keep the original visible rather than netting it away | Disputes team |
| Partial match | One settlement covering many transactions, or one transaction split across settlements | Many-to-many matching with a configurable tolerance and a recorded match rationale | Operations for residuals only |
| Currency and rounding | Conversion applied at a different rate or precision than the ledger used | Store the rate and the source of the rate with every converted amount. Route rate differences to a defined FX difference account | Finance |
| Missing on one side | Payment succeeded at the provider but the ledger write failed, or vice versa | Highest-severity break. Alert immediately with the transaction reference, because this is the class that becomes a real loss | Engineering and operations jointly |
| Unexplained residual | Everything else, which is where undocumented behaviour hides | Never silently written off. Aged, reported as a monitored metric and reviewed weekly | Finance with engineering support |
Two design commitments make the difference. Store the raw provider file exactly as received, so a re-run after a rule fix is possible without asking the provider again. And report unmatched value and unmatched count as monitored metrics with thresholds, because reconciliation that nobody watches drifts quietly for months.
- Idempotent ingestion of provider files so re-delivery of the same file cannot double-count
- Rules as configuration, not code, with each rule versioned and each match recording the rule that produced it
- Replay capability from stored raw files after a rule change, with the previous result retained for comparison
- Break ageing and severity so money-impacting differences outrank cosmetic ones in the queue
- Suspense and clearing accounts modelled explicitly rather than differences being absorbed into a revenue line
- Maker-checker on manual matches and write-offs, with the reason captured as structured data
- Daily close with a signed-off position, not a rolling state nobody has ever declared correct
- Full audit of every match, unmatch and adjustment including who, when and why
Origination
Lending origination, decisioning and KYC or AML workflow
How we build origination and decisioning
Origination is a state machine with external dependencies that fail. We model application state explicitly, make every bureau, screening and verification call idempotent and cacheable with a documented freshness window, and record every decision with the exact inputs and rule version used. Regulators and customers both ask why a decision was made, sometimes years later.
-
Application capture with resumable state
Multi-step capture that survives abandonment, device change and document upload failure. Partial applications are first-class records with their own retention rule, because an abandoned application still contains personal data.
-
Identity verification and KYC
Document verification, liveness, database checks and address validation through licensed providers. For India that includes handling Aadhaar-based flows only through permitted channels, and storing verification outcomes rather than raw identity artefacts wherever the rules allow.
-
Sanctions, PEP and adverse media screening
Screening at onboarding and on an ongoing basis against updated lists. Fuzzy name matching produces false positives at a rate that surprises everyone, so the disposition workflow and the audit of who cleared what matters more than the matching algorithm.
-
Bureau, bank statement and affordability data
Credit bureau pulls with consent recorded, open banking or statement analysis for income and affordability, and caching with an explicit freshness window so a re-decision does not silently reuse stale data.
-
Decisioning with a versioned rule set
A rule engine where policy is configuration owned by risk, not code owned by engineering. Every decision stores the rule version, the input snapshot and the reason codes, so the decision can be reproduced exactly. Where a model contributes, we retain the feature values used.
-
Offer, agreement and disbursal
Offer generation with the mandated pre-contract disclosures, electronic signature, mandate setup for repayments, and disbursal posted to the ledger as a single atomic transaction with the loan account opened in the same commit.
-
Servicing, collections and ongoing monitoring
Repayment schedules with interest accrual as ledger entries, arrears state transitions, forbearance handling, and transaction monitoring feeding suspicious activity workflow. Vulnerable-customer treatment paths designed in rather than added after a complaint.
Compliance engineering
PCI DSS scope, data localisation and regulatory reporting
PCI DSS scope minimisation
The cheapest way to comply is to be out of scope. Ranked by preference:
- Hosted fields or provider SDK. Card data goes from the customer's browser or app directly to the provider. You receive a token. Your servers never see a primary account number.
- Network tokens and provider-held vaults for card-on-file, so recurring billing works without you storing anything sensitive.
- Dedicated vault where you genuinely must hold a PAN. Separate network segment, separate key management with an HSM or managed KMS, its own access model, its own logging, and no application code sharing a runtime with it.
Alongside that: no card data in logs ever, redaction at the logging library rather than at review time, no card data in support tickets or screenshots, and synthetic test cards only in non-production.
Data localisation
- India. RBI expects payment system data for Indian operations to be stored in India. We assert region in Terraform, block cross-region replication by policy, and fail the pipeline on violation rather than relying on a document.
- Cross-border processing where permitted for a specific purpose is designed with explicit deletion and repatriation behaviour and a written retention window.
- Non-production data stays in the same residency boundary, which teams forget until an audit finds a European dataset in a development account.
Regulatory reporting pipelines
Reporting fails for boring reasons: the number in the return cannot be traced to the transactions behind it. We build reporting as a lineage problem.
- Point-in-time reproducibility. A return submitted in March must be regenerable in November with the same figures, which means snapshotting inputs, not recomputing from a mutable table.
- Lineage to source. Every figure drills to the journals and transactions that produced it, so a query from a regulator is an afternoon rather than a project.
- Validation before submission against the schema and the arithmetic cross-checks the regulator applies, so rejections happen in your pipeline and not at the regulator.
- Restatement handled as a first-class case with a versioned submission history and the reason for each restatement recorded.
- Segregation of duties between preparation, review and submission, enforced in the system rather than in an email chain.
Jurisdiction context we design against
- India, RBI. Master directions relevant to your licence type, outsourcing and IT governance expectations, data localisation, and audit rights for the regulator and your internal auditors flowing down to us as a supplier.
- United Kingdom, FCA and PRA. Consumer Duty shaping product and communication design, operational resilience with important business services and impact tolerances, SM&CR accountability, and outsourcing and third-party risk expectations.
- Europe. PSD2 strong customer authentication and exemption logic, open banking interfaces, and DORA-style operational resilience requirements landing on your suppliers as well as you.
Insurance
Policy administration, underwriting and claims
The design decision that defines an insurance platform
Insurance systems fail on versioning. A policy is not a record, it is a sequence of versions with effective dates, endorsements, cancellations and reinstatements, and a claim must be assessed against the wording in force on the date of loss. We model policy as a temporal entity from the start, because retrofitting effective dating into a flat policy table is close to a rebuild.
Policy administration
- Temporal policy model. Versions with effective and expiry dates, endorsements as new versions, mid-term adjustments with pro-rata calculation, cancellation and reinstatement as explicit transitions.
- Product configuration separate from code. Coverages, limits, deductibles, optional benefits and eligibility rules as configuration, so launching a variant does not require a release.
- Rating engine with versioned rate tables and the ability to reproduce any historical quote exactly, including the rate version and factor values used.
- Premium, commission and tax as ledger entries, with instalment schedules, mid-term refunds and broker commission clawback all posted rather than calculated on read.
- Document generation for schedules, certificates and endorsements, with the issued document archived as produced rather than regenerated later from changed data.
Underwriting and claims workflow
- Straight-through processing with referral rules. Automate the clear cases, route the rest to an underwriter with the reason for referral shown, and record the referral rule version.
- Underwriter workbench with the submission, the data pulled, the rule outcomes and a decision record. Decisions are auditable and reproducible, and manual overrides carry a captured rationale.
- Claims first notification of loss capturing structured data plus evidence, with duplicate claim detection and a reserve posted to the ledger at notification.
- Reserve movements as journal entries so incurred position, payments and recoveries reconcile without a spreadsheet.
- Fraud indicators surfaced, not decided. Scoring supports a human decision; declining a claim automatically on a model score is a customer-outcome risk we design against.
- Complaints and vulnerable-customer paths as tracked workflows with response timers, which UK Consumer Duty expectations make load-bearing rather than optional.
A UK insurance broker we worked with had eleven years of policy history in a system with no effective dating. Reconstructing which wording applied to each historical claim was the largest single piece of that engagement, and it was entirely avoidable at original design time.
Answers
BFSI engineering questions
Is Redcubical Systems a regulated financial entity?
No. We are a software engineering firm. We are not a bank, an NBFC, a payment institution, an insurer or a broker, we hold no financial services licence, and we do not provide regulatory, legal, actuarial or investment advice. We build systems that make your regulatory obligations implementable and evidenceable, working to the interpretation your compliance function supplies.
Why are reconciliation engines harder than they look?
Because the difficulty is not matching, it is explaining differences. A real engine needs many-to-many matching with tolerances, timing windows that span settlement cycles, currency and fee normalisation, duplicate and reversal handling, and a break taxonomy that routes each unmatched item to whoever can resolve it. Teams budget for the matcher and then spend three times as long on exceptions.
What is wrong with storing balances as a mutable column?
It destroys your ability to answer the only question that matters during a dispute: how did this balance come to be. We use append-only double-entry journals where balances are derived, with optional materialised snapshots for performance. Corrections are new reversing entries, never updates. If your ledger has an UPDATE statement against amounts, you have a reconciliation problem waiting.
How do you keep PCI DSS scope small?
By never letting cardholder data touch your servers. Hosted fields or a payment-provider SDK collect the card, the provider returns a token, and your systems store and use only the token. That typically reduces a merchant to SAQ A or SAQ A-EP territory rather than full assessment. Where you must hold a primary account number, we isolate it in a dedicated vault with its own network, keys and access model.
Do you work with UPI and NPCI rails?
Yes, through a sponsor bank or licensed provider, which is the only lawful route for a non-licensed entity. Practically that means collect and pay flows, mandate handling for recurring debits, callback reliability, deduplication on retries, and a settlement reconciliation loop against the bank statement rather than trusting the callback.
What does ISO 20022 migration involve beyond a format change?
The format change is the small part. ISO 20022 carries richer structured data, so the real work is data enrichment, longer field handling, structured address and party information, truncation rules during coexistence with legacy MT messages, and reconciliation across both formats while both are live. Systems that map ISO 20022 down to legacy fields lose the value and inherit the cost.
How do you handle eventual consistency when money is involved?
We avoid it on the posting path. The ledger write is a single atomic transaction in one database, and cross-service coordination uses the transactional outbox pattern with idempotent consumers and sagas that have explicit compensating actions. Read models may lag; the ledger may not. Distributed transactions across services for money movement is the design we argue against most often.
Can you build for RBI data localisation requirements?
Yes. Payment system data for Indian operations is stored in Indian regions, asserted in infrastructure code and verified in the pipeline rather than promised in a document. Where processing abroad is permitted for a specific purpose, we design the deletion and repatriation behaviour explicitly, and your compliance function confirms applicability for your entity and licence type.
Start with a ledger, payments and reconciliation review
Three weeks, fixed fee. You get a ledger and idempotency assessment, a payment rail and settlement review, a reconciliation break analysis against real files, a PCI scope map and a costed remediation plan. Yours to keep either way.