Article map
Corporate payment risk is often associated with the moment an instruction is released to a bank. By that stage, many critical decisions have already occurred. An obligation has been created, a beneficiary selected, payment data prepared, supporting evidence attached and approval routed. If any of those upstream elements is false or compromised, a final bank authorisation may merely approve the wrong payment more efficiently.
A strong payment-control framework therefore follows the complete journey from business obligation to bank settlement and accounting reconciliation. It combines preventive, detective and responsive controls while preserving source, decision, approval and status. This article sets out that lifecycle.
1. Begin with a valid business obligation
Payment control starts before treasury receives an instruction. The organisation should know why it owes the amount, who approved the commercial or statutory obligation and whether supporting records exist.
Source systems may include approved invoices, payroll, tax, debt, investments, intercompany settlements and treasury deals. Each source should carry its own approval and status. Treasury should not be expected to reperform commercial approval, but it should reject records that lack required evidence or fall outside authorised source channels.
Manual treasury payments need a defined purpose taxonomy and enhanced review because they bypass normal source workflows.
2. Govern the beneficiary independently
The beneficiary record is a high-risk master. Account number, name, bank identifier, country, currency and payment method should be created or changed through controlled onboarding.
The person requesting a beneficiary should not be the sole person validating or activating it. Material changes should be verified through a trusted channel independent of the change request, particularly where email compromise is possible.
Payment preparation should use the approved master rather than free text. Temporary or one-time beneficiaries should not become an uncontrolled exception path.
3. Preserve source-to-payment lineage
Each payment should retain a link to the source obligation, entity, account, beneficiary and supporting documents. The system should prevent the same obligation from being paid twice through different batches or channels.
Lineage enables a reviewer to answer: what is being paid, under which authority, to which verified account, from which legal entity, on what value date and through which bank route?
Where aggregation is used, such as payroll or supplier batches, the batch should reconcile to its components. A valid batch total without controlled line items is insufficient.
4. Validate payment data before approval
Automated validation should cover required fields, format, currency, bank account, value date, payment method, account permission, available balance, duplicates and sanctions or compliance screening where applicable.
Business rules can identify unusual amount, changed beneficiary, out-of-pattern country, weekend value date, split payment, dormant vendor, urgent flag or deviation from contract. Alerts should be risk-based so that reviewers are not overwhelmed.
Validation results and any accepted warning should remain part of the payment record.
5. Apply policy-driven approval
Approval matrices should consider legal entity, account, payment type, amount, currency, beneficiary risk and urgency. Different authorities may apply to supplier payments, tax, intercompany transfers, funding and investments.
The workflow should enforce independence between preparation and approval. High-risk payments may require an additional approver or specialist review. Delegations should be time-bound and visible.
Approvers need decision context, not merely amount and beneficiary name. They should see source, changes, warnings, duplicate checks and post-payment liquidity effect.
6. Enforce segregation across the lifecycle
Maker-checker is one element of segregation, but role design should cover source creation, beneficiary maintenance, payment preparation, approval, bank administration, release, reconciliation and access administration.
A user who can change a beneficiary and approve a payment creates a material conflict even if another user prepared the batch. Privileged administrators should not be able to alter roles or data without independent oversight.
Conflicts should be identified during role assignment and periodically recertified. Transaction monitoring can also detect circumvention, such as splitting amounts below approval thresholds.
7. Secure authentication and bank release
Payment release should use strong authentication, controlled devices or channels and bank signing authority aligned with internal policy. Credentials and tokens should not be shared.
Host-to-host, API and SWIFT connectivity can reduce manual rekeying, but technical automation must retain approval status and message integrity. The transmitted message should be traceable to the approved payment version.
Changes after approval should invalidate or restart approval. The platform should prevent a user from editing account, beneficiary, amount or date while retaining the original approval.
8. Monitor transmission and bank response
A payment is not complete when sent. The system should record transmission, technical acknowledgement, bank acceptance, rejection, pending status, settlement and return.
Response codes should be normalised while preserving bank detail. A technical success means the message reached the bank; it does not necessarily mean the bank accepted or settled the payment.
Unacknowledged or pending high-value items should escalate before the business deadline. Users need to know when to investigate rather than assume silence means success.
9. Control urgent and exceptional payments
Urgent payments are necessary, but urgency can be exploited to bypass verification. Policy should define eligible reasons, maximum amount, required evidence, authorised users and independent call-back or confirmation.
The emergency route should remain within secure channels where possible. If bank portals or manual instructions are used, dual control, verified contacts and post-event reconciliation are essential.
Every exception should be reviewed after settlement to determine whether the underlying process, planning or data should change.
10. Prevent and detect duplication
Duplicate logic should compare source reference, beneficiary, account, amount, currency, date and invoice or deal identifiers. Exact duplicates are only one risk; near duplicates and split instructions can also matter.
The time window should reflect the business. Recurring payroll or rent may legitimately repeat, while a unique tax reference should not.
A duplicate alert should not be dismissed without evidence. The system should retain the decision and approver.
11. Connect payment approval to liquidity
Payment workflow should consider available cash, account limits, current-day position and funding action. An approved obligation remains valid, but its execution timing may require treasury intervention.
The platform should distinguish a policy hold from a liquidity hold and preserve legal due date. Delaying a payment to manage cash should require authorised decision and assessment of commercial or legal consequence.
This connection prevents payment teams and liquidity teams from operating on conflicting versions of expected outflow.
12. Reconcile settlement to bank and ledger
Settled payments should match bank transactions, payment records and accounting entries. Differences may arise from fee, partial settlement, rejection, return, value date or amount conversion.
Automated matching can use bank reference, end-to-end identifier, amount, currency and date. Unmatched items should be assigned and aged.
Reconciliation closes the control chain. Without it, treasury may not detect a duplicate, returned payment or incorrect bank debit until the beneficiary complains or the month-end close.
13. Manage exceptions as controlled records
Rejected, delayed, altered, duplicate, suspicious and unreconciled payments should enter a common exception process. The record should show status, severity, owner, deadline, evidence, communication and resolution.
Repair should not destroy history. The original instruction, bank response and revised payment should remain linked.
Material incidents should trigger root-cause review, control assessment and possible fraud or cyber escalation.
14. Retain evidence independently
The organisation should be able to reproduce the complete payment decision: source obligation, beneficiary verification, validation, approvals, transmission, bank response, settlement and reconciliation.
Audit history should record user, time, action and before-and-after values. Evidence should be protected from ordinary user deletion and retained according to policy and legal requirements.
Screenshots and email chains are weak substitutes for system-generated records because they can be incomplete and difficult to authenticate.
15. Monitor payment-control performance
Metrics can include straight-through processing, rejection rate, urgent payments, changed-beneficiary payments, duplicate alerts, approval ageing, payments after cut-off, exceptions past service level, reconciliation breaks and access conflicts.
Volume measures should be paired with value and risk. One high-value unusual payment can matter more than hundreds of routine items.
Trend analysis should inform process, bank and master-data improvement rather than remain a compliance report.
Practical illustration: stopping a valid-looking fraudulent change
A supplier email requests an urgent bank-account change and attaches an invoice already approved in the ERP. The invoice is genuine, and the amount matches historical purchases. Under a weak process, the payment could pass source and amount checks.
The beneficiary-control workflow flags a new account, requires independent verification using the supplier's existing contact record and identifies that the request did not originate through the approved portal. The supplier confirms its account has not changed. The payment is held and the incident escalated.
The control succeeded because beneficiary verification remained independent of the apparently valid obligation.
Implementation checklist
An end-to-end payment-control framework should include:
- approved and traceable source obligations;
- independently governed beneficiary records;
- source-to-payment and batch-to-line lineage;
- field, format, duplicate and risk validation;
- policy-driven approval with decision context;
- lifecycle segregation and access recertification;
- strong authentication and controlled bank release;
- acknowledgement, acceptance and settlement monitoring;
- defined urgent-payment route;
- liquidity and cut-off integration;
- bank, payment and ledger reconciliation;
- exception ownership and root-cause review;
- immutable audit history and evidence; and
- value- and risk-based performance metrics.
Common control failures
Common failures include relying only on bank dual approval, allowing free-text beneficiary data, accepting emailed changes without independent verification, editing payments after approval, confusing technical transmission with bank acceptance, treating urgent as exempt, ignoring near duplicates and failing to reconcile returns.
Another failure is separating payment operations from access administration. A well-designed workflow can still be compromised if privileged users can grant themselves conflicting roles without review.
Closing perspective
Payment control is a connected chain. Its strength depends on the validity of the obligation, integrity of the beneficiary, quality of the data, independence of approval, security of transmission, visibility of status and completion of reconciliation.
When the full journey remains linked and evidenced, treasury can increase straight-through execution without sacrificing control. Automation then removes manual handoffs while preserving the context required to prevent, detect and resolve payment risk.
Frequently asked questions
What are the main stages of payment control?
The control chain includes valid obligation, beneficiary governance, payment preparation, validation, approval, secure transmission, bank acceptance, settlement, exception handling, reconciliation and evidence retention.
Is bank dual approval enough to control payments?
No. Dual approval at the bank cannot correct a false obligation, compromised beneficiary record, duplicate instruction or collusive approval. Controls must operate throughout the lifecycle.
How should urgent payments be controlled?
Use a documented emergency route with strict eligibility, independent verification, reduced limits where possible, dual control, secure transmission and mandatory post-event review.