Build a Treasury Payment Approval Matrix
Map payment roles before discussing access or approval configuration.
A request for dual approval on payments looks like a simple settings question. It is not. Before you touch any configuration screen, you need to know who creates payments, who reviews them, and what happens when the usual approver is unreachable. Skip that step and you end up building a workflow that does not match how the company actually runs, or you hand over access based on an incomplete picture. This is the conversation that decides whether the setup holds up the first time someone is out sick or traveling, not the one where you click through a menu.
Why This Conversation Goes Wrong
Most of these calls go sideways because the specialist starts with the interface instead of the workflow. Someone asks "who should have approval rights on this account" and writes down whatever names the customer gives. That feels efficient. It is actually a trap. Names change jobs, go on leave, and leave the company, but the underlying business function stays. A matrix built around a person instead of a role needs to be rebuilt every time staff turns over, and nobody notices until a payment sits stuck because the named approver no longer works there.
The second failure is more subtle. Customers rarely have a documented answer for what happens when the usual approver is unavailable. They assume someone will figure it out, and that assumption survives right up until an urgent payment needs to go out and both approvers are on a plane. If you do not ask about the exception path directly, you will not hear about the gap until it becomes a problem for the customer, not for you.
The third failure is overpromising. A specialist under pressure to move the call forward will sometimes suggest that a certain configuration is available before checking whether the bank's process actually supports it for that account type. That creates an expectation you cannot meet, and it damages trust faster than a slower, more accurate answer would.
How to Prepare
Before you get on the call, pull whatever account documentation exists and list the payment types the company actually uses. Payroll, vendor payments, tax payments, and urgent or wire transfers often follow different approval paths, and treating them as one blanket workflow is a common mistake.
Build a simple matrix ahead of time with columns for payment type, preparer, approver, backup approver, and how the exception gets recorded. You are not filling this in yourself. You are using it as the structure for the questions you ask the customer. Walking in with this template means you ask about backups and documentation before the customer brings it up, rather than reacting to whatever they happen to mention first.
If the company is also introducing a new payment file format around the same time, it is worth reading Prepare a Treasury Payment File Test beforehand, since file testing and approval setup often get scheduled close together and the two conversations can blur if you are not ready for both.
What to Say
Priya is the controller at a small nonprofit. One accountant prepares vendor payments, and two executives, Tom and Renee, approve them. The specialist opens by asking Priya to describe how a payment actually moves through the company today, not what settings she wants changed.
Priya says, "Our accountant prepares every vendor payment, and either Tom or Renee signs off before it goes out."
The specialist asks, "What happens when Tom and Renee are both unavailable on the same day, say during a conference or a family emergency."
Priya pauses. "Honestly, we do not have a clear answer for that. Someone usually just calls around until they reach one of them."
The specialist responds, "That is common, and it is worth fixing now rather than during an actual emergency. Is there anyone else in the company who could act as a backup approver for vendor payments specifically."
Priya considers it. "Our operations director could probably do it, but we have never given her that authority in writing."
The specialist says, "Then before we configure anything, ask your leadership to name a backup approver for each payment type, even if it is meant to be temporary. I also want to keep payroll and tax payments separate from vendor payments, since a lot of companies route those through different people. Once you have that decided internally, I will document it and send you a summary, along with where your authorized administrator submits the actual setup request."
Notice what she did not do. She did not promise that Renee's assistant can be added as an approver, and she did not tell Priya the bank will approve any specific configuration. She asked questions, named the gap, and handed the decision back to the company, which is exactly where it belongs.
Mistakes to Avoid
- Do not accept an employee's name as the entire approval record. Ask for the role or function behind the name, since staff turnover should not force a rebuild of the whole matrix.
- Do not promise a configuration is available before you confirm the bank's actual process and eligibility rules for that account.
- Do not let one exception plan cover every payment type. Payroll, tax, vendor, and urgent payments often need separate backup approvers and separate documentation.
- Do not skip the question of how an exception gets recorded. An approval made without a documented trail is a gap that surfaces later, usually during an audit or a dispute.
- Do not close the call without naming the next concrete step. A vague plan to follow up leaves both sides unclear on who does what.
How to Practice and Score It
A manager can run this as a short role play, playing the customer and giving deliberately incomplete answers, the way Priya did before she was asked about backups. Score the specialist on five things. Did they ask about roles and payment flow before mentioning any settings. Did they ask directly about the exception path instead of waiting for the customer to volunteer it. Did they separate payment types instead of treating all payments as one workflow. Did they avoid promising a specific configuration before confirming eligibility. Did they end the call with a clear next step and a named owner for that step.
This is also a good scenario to rehearse on your own, not just in a manager led drill. Banking practice conversations let you run this exact exchange against an AI counterpart, try different customer responses, and see where your questions left a gap before you are on a real call with real payments at stake. The same role mapping skill applies when you Prepare a Positive Pay Onboarding Discussionsince both conversations depend on knowing who actually does the work before you talk about system access.
A good approval matrix conversation is slow on purpose. You are not there to close a settings request quickly. You are there to make sure the request reflects how the company actually operates, including the parts they have not written down yet. Get the roles and the exception path right first, and the configuration step becomes easy.
Practice these next
Prepare staff for banking workflow changes through clear coaching organized by role.
Map daily banking roles before a business asks for account access changes.
Clarify operational and technical owners before an integration discussion.
Clarify who acts when a business spots a suspicious payment.
Use ownership and exception questions before a business tests payment files.
Clarify file ownership and exception routines before a treasury implementation review.