Payment Aggregator With Manual Reconciliation and a Duplicate Settlement

The failures sit in three layers. At the transaction layer, 3% of items unmatched after 24 hours is not a rounding issue at 2.3 million transactions a day; it means a material population is not verified daily, so errors and duplicates can pass undetected. At the authorisation layer, one operations employee can create a vendor, change bank details and release payment. That is a classic segregation-of-duties failure: the same person can invent or alter a payee and pay it. At the technology layer, API keys can be issued without maker-checker, which creates an access-control and fraud path. The incident response is also weak: a ₹1.2 crore duplicate was closed as 'processor error' without root-cause analysis, so the underlying control gap remains. The audit committee is being told reconciliation is 'substantially complete', which is not a measurable assurance statement. These failures combine: an unmatched item can become a duplicate settlement, the person who can change payee details can conceal it, and the board will not see it because reporting is opaque. Regulatory exposure follows from safeguarding client funds, operational resilience and accurate reporting, not merely from the loss itself.

Preventive controls should start with strict segregation: vendor master creation, bank-detail changes and payment release must sit with different roles, with maker-checker at each step and dual approval for any change to beneficiary details. API key issuance, rotation and revocation should require two approvers, be logged, and be limited to named service accounts. Payment release should use transaction limits, velocity checks and a real-time duplicate-detection rule that blocks same-merchant, same-amount payments within a defined window. Detective controls should include automated daily reconciliation against bank and scheme files, with ageing buckets, exception ownership and a hard rule that unmatched items above a threshold are escalated within 24 hours. A daily settlement dashboard should show opening balances, inflows, outflows, unreconciled items and ageing, signed off by an operations manager independent of payment release. Access reviews should be quarterly, and privileged access should be recertified. Incident management should require root-cause analysis, a corrective-action owner and board reporting for incidents above a defined threshold. Internal audit should have technology capability or co-source it, and vulnerability assessments should be scheduled at least annually with remediation tracking.

The one-page 'substantially complete' summary is not decision-useful. The committee should receive a dashboard with defined metrics: percentage of transactions automatically reconciled within 24 hours, value and count of unmatched items by ageing, duplicate-payment attempts blocked, payment exceptions approved outside normal limits, privileged-access changes, incident ageing and repeat incidents, and audit issue closure rates. Each metric should have a target, a trend and a named owner. The committee should also see a root-cause report for the ₹1.2 crore duplicate and evidence that the fix has been tested. On the licence application, the committee should ask whether the regulator's operational-resilience and safeguarding expectations can be met at 60% higher volume. That requires a capacity and control-scalability assessment, not just a business case. It should ask what breaks first under stress, whether reconciliation will remain manual, whether internal audit coverage is adequate, and whether any incidents or control gaps need to be disclosed. The committee should minute its conclusion and require management to remediate material gaps before the volume increase goes live. If the gaps are material, the committee should tell the board that growth should be phased, with a gate on control readiness.