Bank Mandates and Signatory Management

A bank mandate is the list of people the bank will take instructions from, and what those instructions may be. Treasury spends its design effort on the approval matrix inside the payment factory. The bank does not read that matrix. It reads the mandate in its own files. A leaver who is still on the mandate can still move the account, whatever the TMS says.

This is the control underneath eBAM. eBAM is how the change travels. This page is what the change is, and why the paper list rots.

Two lists, one account

Keep them separate in your head or you will reconcile the wrong one:

A payment that fails the TMS never reaches the bank. A payment that passes the TMS and fails the mandate comes back as a reject, often days later, often as a format or authorisation code nobody mapped. A payment that the TMS would have blocked, sent by a signatory the bank still accepts, never hits the TMS at all. That last case is the one audits find: the online-banking token of someone who left, still live, because the mandate was not changed.

Segregation of duties inside the TMS does not repair a mandate. Four-eyes in the system and one remaining signatory at the bank is one control, not two.

How the list goes stale

The account is opened. The mandate form is signed by whoever the project could find that week. It is scanned. It is filed. Then:

• Someone leaves. HR tells IT. IT disables the network account. Nobody tells the bank, because "the bank" is not a ticket queue with an owner.
• Someone changes role from treasurer to a job that should not sign. The TMS role is updated in the same week. The mandate is "on the list for the next refresh", which is not a date.
• A country opens an account locally, with local signatories, and group treasury hears about the account when the statement arrives. The mandate exists. Group does not have a copy.
• A refresh project collects "current signatories" by asking the subsidiaries. They confirm the list they remember, which is the list from the last refresh.

eBAM, where the bank supports it, turns the change into a message you can prove was sent and accepted. It does not create the inventory. Digitising a wrong signatory list, as the eBAM page already says, makes the wrong data faster. The inventory comes first: every account, every power, every name, dated, with the bank's copy and the company's copy compared. Bank account rationalisation cuts the number of lists you have to keep true. It does not remove the job.

The operating rule

1. One owner for mandate changes, named, not "local finance".
2. A leaver is a mandate change with a due date measured in days, not in the next annual review.
3. The TMS approver list and the bank signatory list are reconciled on a cycle. Differences are items, not a spreadsheet nobody opens.
4. Powers are specific. "Full rights" on a form is how an enquiry user becomes a payment authoriser.
5. Where the bank can take an electronic mandate, use it. Where it cannot, the paper change is still someone's job, with the same due date.
6. An AI agent is not a signatory. If a design proposes to put a system user on a bank mandate, stop. The mandate is for people the bank can hold responsible. The system's authority stops at the TMS.

What I left out, on purpose

• Country forms and notary rules. A French mandate, a German one and a US corporate resolution are not the same document. Publishing one as the template would be wrong in the other two countries.
• The message set eBAM uses. That is the eBAM page. This one is the list the message is about.
• Personal liability of a signatory. It is real and it is legal advice. I am not giving it. The operational fact is enough: the bank will act for the names on its form.

The approval matrix is the control you designed. The mandate is the control the bank will apply. Both have to name the same people, and both have to drop a name when the person has gone.

See also electronic bank account management, segregation of duties in treasury systems and can an AI agent approve its own payment.