How treasury policies and procedures are set, run and revised

Treasury policy work runs as a loop. The board or its finance committee sets scope and authority. The treasurer writes policy, and the treasury team turns it into procedures. Controls and system access are designed alongside. Findings from monitoring and audit then feed changes back into the documents.

The steps in order

1. Set scope and governance. The CFO drafts this and the board or audit committee approves it. It defines what treasury covers, such as cash, liquidity, borrowing, investments, foreign exchange and bank relationships. It also names who holds authority to commit the organisation and which committee oversees treasury decisions.

1. Write and publish treasury policies. The treasurer owns the drafting. Policies state limits and principles: approved counterparties, permitted instruments, hedging stance and minimum liquidity. Approval follows the authority set in step one. Once signed off, each policy goes into a single controlled location with a named owner and a version history, so staff never work from an old copy saved on a laptop.

1. Develop procedures. Treasury managers and analysts write these, ideally with the people who will perform them. A procedure covers what policy leaves out: who initiates a payment, who releases it, which cut-off applies, and what happens when a bank portal is down.

1. Design and confirm internal controls. Treasury works with the internal control or risk team here. Typical controls include segregation between payment initiation and release, dual approval above set thresholds, and a bank mandate that matches the internal authority matrix. Confirmation means walking a real transaction through end to end and recording the result in a cycle memo that auditors can rely on.

1. Define system security requirements. IT security and the treasury system owner agree user roles in the treasury management system and every bank portal. Token custody, payment file integrity, password rules and prompt removal of leavers all belong in this step. Bank-side permissions are easy to forget, and they matter as much as internal ones.

1. Monitor how procedures perform. The treasury manager and the financial controller share this. Bank reconciliations, limit breach reports, failed payment logs and counterparty exposure reviews show whether procedures hold up in practice. Exceptions get logged with a cause, not just a fix.

1. Audit the procedures. Internal audit tests controls against the documented design, and external auditors do the same for their own purposes. Treasury supplies requested documentation and samples. Each finding is recorded along with any adjustment it requires and an agreed owner.

1. Revise. The treasurer decides what changes. Triggers include audit findings, a new bank or entity, a system migration, a regulatory change or repeated exceptions from monitoring. Procedure edits can usually be approved within treasury. Anything that alters a limit or an authority goes back through the approval route set out in step one.

Where practice drifts from the documents

The written version usually describes a tidy sequence. Real operation is messier. Procedures often get updated informally after a bad week, while the published copy stays as it was. Bank mandates lag behind staff changes. Emergency payment routes, set up once for a genuine crisis, quietly become normal.

Control testing can also mislead. A walkthrough done with the most experienced analyst shows the control working. The same test with a cover person on a busy afternoon may show something different.

System roles drift too. People collect access as they move between jobs, and nobody removes it because nothing breaks.

Questions to ask the people who run it

• Which procedure do you actually follow for a same-day urgent payment, and where is it written down?
• When did someone last release a payment they also initiated, and why?
• Who can change bank details for a counterparty, and who checks the change?
• Which bank portals have users who no longer work in treasury?
• What happens when the treasury system is unavailable? Is there a manual route, and who approved it?
• Which policy limits get breached often enough that people stop reporting them?
• When an audit finding was last closed, did the procedure document change or just the behaviour?
• Who covers when the usual approver is away, and does the bank mandate reflect that?
• Are there spreadsheets doing work the system is supposed to do?
• If a new entity or bank account were added tomorrow, who would update the policy, the mandate and the system roles?

Answers that differ between people doing the same job are the most useful ones. They point to where a change will meet resistance, or where a control exists only on paper.

Handoffs that need watching

The weak points sit between owners. Policy approved by the board but never translated into a procedure is common. So is a control designed by the risk team that treasury staff find unworkable and route around. Security requirements written by IT sometimes miss the bank side entirely. Audit findings can land with internal audit and stall there because no one in treasury was named to fix them.

Before changing anything, map who hands what to whom. Confirm each receiving party knows the handoff is theirs.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.