A deposit pricing tool is software that helps a bank or credit union decide what to pay depositors: the rate sheet the rate committee sets, and the exceptions approved when a customer or member asks for more. Buying one is the easy part. It pays only if branch managers send their requests through it and approvers decide there, and branches route around any tool that slows them down in front of a member or gives answers nobody can explain. Botminds' Deposit Pricing answers each request in seconds with a cited counteroffer and leaves the decision with a named approver. This page sets out how to roll a tool like it out so that it is trusted: a ladder of four rungs, shadow, compare, approve with sampling, approve, each with a measure that has to move before the institution climbs to the next.
Figures on this page from the solution are sample data on a fictional institution, Norrell Federal Credit Union, a $6.8 billion credit union with 38 branches. The rollout ladder and its eight weeks are our suggestion, not a measured result or a commitment.
A trust ladder for a deposit pricing tool: what changes on each rung, and the measure that moves it
1Shadow
What happensThe agents price every request; nobody sees their answer. The desk decides as it does today.
What is measuredAgreement: share of decisions within 5 bp of the agents’ counteroffer, by approver and product.
To climbAgreement stable for two weeks, and every large gap explained.
2Compare
What happensThe approver sees the counteroffer beside the request and decides, with a reason code.
What is measuredOverride rate, and the reasons approvers give for differing.
To climbOverrides concentrated in reasons the policy accepts, not in “did not trust it”.
3Approve with sampling
What happensThe branch requests in the thread; approvers decide there; a second reviewer re-checks a sample.
What is measuredSample error rate: decisions the reviewer would have priced differently; disclosure match.
To climbNo disclosure mismatch and few sample disagreements for a month.
4Approve
What happensEvery exception runs through the thread; the sample shrinks to an audit test.
What is measuredClock compliance, consistency gaps by branch, and money kept against forecast.
To climbThe measures become the monthly ALCO line.
What is a deposit pricing tool, and why branches route around one
A deposit pricing tool is any system that sets, recommends or approves deposit rates: a rate sheet manager, an exception workflow, a pricing model, or all three. The ones built for exceptions sit between the branch and the pricing desk, and that is where they fail. A branch manager with a member at the desk will use whatever gets an answer fastest, and if the tool adds a form, a queue and an unexplained number, the phone wins.
Routing around takes three forms, and each leaves a trace. Requests keep arriving by phone and email, so the tool's volume is a fraction of the exceptions the core shows. Approvers decide outside the tool and key the result afterwards, so every decision shows a recommendation overridden. Or branches stop asking, and price at the board rate, so exceptions fall while members leave. A rollout plan has to watch for all three, which is why its measures come from the core and the decision log, not from a login count.
Volume shows where the risk sits. In September the sample credit union received 2,812 exception requests. Two in three were decided at the branch, within branch authority; the rest went to the Deposit Pricing Manager or the rate committee.
Two thirds of exceptions are decided at the branch, so that is where trust is won or lost
Will branch staff trust automated counteroffers? What the research says
Branch staff will trust automated counteroffers if they can see why each number is what it is and can change it within their authority. The research on people and algorithms points both ways. People tend to abandon an algorithm once they see it make a mistake, even when it outperforms them; but in three experiments Dietvorst, Simmons and Massey found that people were far more willing to use an imperfect algorithm when they were allowed to adjust its forecasts, and that they forecast better when they did (Management Science, 2018). The preference held even when the modifications allowed were small.
That finding argues for a counteroffer the approver can move, not a rate the tool imposes. Deposit Pricing's rate dial lets an approver counter at any rate between the board rate and the ask, and shows the cost, the chance the money stays and who may approve at each point before the approver commits. The control is real and bounded: the approver can go anywhere inside their authority, and nowhere above it.
The other half of the research is a warning about overrides. Studying bail decisions, where judges could depart from an algorithm's recommendation, Angelova, Dobbie and Yang found that "90% of the judges in our setting underperform the algorithm when they make a discretionary override, with most making override decisions that are no better than random. Yet the remaining 10% of judges outperform the algorithm in terms of both accuracy and fairness when they make a discretionary override" (NBER working paper 31747; Review of Economic Studies, 2026). Bail is not deposit pricing. The lesson that carries over is that overrides are neither good nor bad in general; they differ by person, and only a tool that keeps each override with its reason and outcome can tell which approvers add information.
What a branch manager and an approver see: a counteroffer whose every line opens its source
A four-rung trust ladder, each rung with its measure
The ladder exists so that nobody has to take the tool on faith. On the first rung, shadow, the agents price every request and nobody sees the answer; the institution learns how often its own approvers land near the counteroffer, by person and by product, and investigates every large gap. Some gaps will be the tool's mistakes, such as an offer it misread; others will be the approver's, such as a counteroffer priced against last week's FHLB sheet. Both are useful.
On the second rung, compare, approvers see the counteroffer and decide with a reason code. The measure is the override rate and, more usefully, the reasons. Overrides for reasons the policy accepts, such as a relationship the agents could not see, are the tool working. Overrides coded "did not trust it" are the rollout not working yet. On the third rung, approve with sampling, the thread becomes the place where requests are made and decided, and a second reviewer re-checks a sample of decisions and every disclosure against its approval. On the fourth, the sample shrinks to an audit test and the measures become a line in the monthly ALCO report.
Eight weeks from replay to approval in the thread, as a suggested plan
- Matrix, data, replay on past decisionsWk 1–2
- ShadowWk 3–4
- CompareWk 5–6
- Approve with samplingWk 7–8
What is a pricing authority matrix, and why it goes in before the tool
A pricing authority matrix is the table that says who may approve how far over the board rate, by product and amount. It goes in before the tool because the tool's main job is to route each request to the person the matrix names, and to make it impossible for anyone else to approve. A tool installed on an unwritten matrix will encode whatever the branches currently do, including the habits the matrix should stop.
Writing the matrix forces decisions most institutions have deferred. Whether a branch manager may approve on certificates over $1 million; whether money market accounts get the same authority as certificates; whether savings and checking accept exceptions at all. In the sample matrix, version 14, branch managers may approve up to 15 basis points on certificates up to $1 million and 10 on money market accounts, nothing above $1 million, and nothing on savings or checking, where the board rate is final.
The matrix the tool enforces, and the rule that a change needs a second person
The matrix is also the main lever after go-live. The pending change on that screen would raise branch authority on three- and six-month certificates from 15 to 20 basis points, because 253 short-term requests a month reach the pricing desk at 16 to 20 basis points; the agents estimate 41% of them would then be decided at the branch, at an added cost of about $38,000 a year. That is the trade a rollout manages: faster answers at the branch against a slightly higher price, decided by the CFO as checker, not by the tool.
How do you train branches on exception pricing?
Train branches on exception pricing by role and by the decision each role makes, not by screens. A branch manager needs to know what a complete request contains, how to read a counteroffer to a member, and why she can never approve her own request. A pricing manager needs to know the dial, the reason codes and when to send a request to the committee. Training that walks everyone through every screen produces people who know where buttons are and not why the price is what it is.
Who is trained on what, and the one decision each keeps
Today
Phones the desk, explains the member’s situation from memory, and relays an answer.
With agents
Writes one sentence and attaches the offer; reads the counteroffer’s lines to the member in plain words; delivers the disclosure.
Still theirs: The conversation with the member, and approvals within branch authority on staff requests
Today
Builds every answer from the core, a rate survey and the FHLB sheet.
With agents
Uses the dial to counter at any rate within authority, with a reason code and an override code when differing from the agents.
Still theirs: Every decision up to +40 bp
Today
Sees exceptions as a monthly count.
With agents
Votes on urgent requests above authority inside a clock, and on board-rate proposals drafted from the month’s exceptions.
Still theirs: Decisions above authority and every board rate
Today
Reconstructs who approved what from email and core override reports.
With agents
Reads every action by people and agents, read-only, and exports a masked file for the period chosen.
Still theirs: The independent test of whether policy was followed
Two habits matter more than any feature. Branch managers should attach the offer every time, because an unreadable or missing offer is marked unverified and priced as such. And approvers should write the note. A reason code says which policy reason applied; the note says what the approver saw, and it is what an auditor reads a year later.
What happens when a branch overrides the tool
When an approver decides differently from the agents' counteroffer, the decision stands, and the difference is kept with it: the agents' rate, the approved rate, the reason code and an override code. Nothing is blocked. A branch manager cannot override in the sense of approving above her authority; the tool routes that request to whoever may approve it.
Approving as checker, with a reason code, a note and what happens next
Tracking the gap by approver is the point. Over a quarter the institution can see whose overrides tend to keep money the agents expected to lose, and whose tend to pay more for no measurable gain, which is the bail study's lesson applied to deposits. The Financial Stability Board's final sound practices on AI name the opposite risk too, warning that over-reliance and automation bias can weaken human oversight, and that "Over time, sustained reliance on AI may also diminish staff expertise, judgement and challenge capability" (FSB, Sound Practices for Responsible Adoption of AI, 15 October 2026). An override rate that falls to zero is not success. It may mean nobody is looking.
How long does deposit pricing implementation take?
A deposit pricing implementation takes as long as the matrix, the data connections and the trust ladder take, and the ladder is the long part. The connections are few: a read-only pricing view from the core banking system, the FHLB and brokered rate feeds, the ALM model's marginal cost, the board rate tables, and a write-back of the approved rate with its approval number. The plan we suggest climbs from replay to approve with sampling in eight weeks, and extends any rung whose measure has not moved.
What the institution brings decides the first two weeks: its deposit pricing policy, its authority matrix, its board rate sheets and a sample of past exception requests with their outcomes. The past requests are replayed so that the counteroffer the agents would have made can be compared with the decision actually taken, before any branch sees the tool. That replay is where surprises surface while they are cheap, and where the matrix can be revised before any branch depends on it.
How do you measure adoption of a pricing tool after go-live?
Measure adoption of a pricing tool by what moves through it and what happens afterwards, not by how many people log in. The useful measures compare the tool with the core, so that work done around it shows up.
Seven adoption measures, each checkable against the core or the decision log
- Coverage
Exceptions booked in the core that have an approval number from the tool, as a share of all rate overrides. Anything else was decided around it.
- Clock compliance
Requests decided inside their clock, by channel. The sample design target is two hours for a member at the branch.
- Override rate and reasons
By approver and product. Watch both a high rate and a rate that falls to zero.
- Override outcomes
Whether money approved above or below the counteroffer stayed, against the retention estimate.
- Consistency gaps
Branch and channel medians against like requests; in the sample, no branch more than 5 bp from the median.
- Disclosure match
Signed disclosures whose terms equal the approval: the target is all of them.
- Requests that stop
Exceptions falling at a branch while maturities run off at the board rate: branches that stopped asking.
Where this deposit pricing tool fits, and where it does not
Deposit Pricing fits a bank or credit union with branches and a contact center, where exception requests arrive from staff sitting with depositors, where a written authority matrix exists or is about to, and where the pricing desk spends its day looking things up. It is built to keep decisions with named people and to leave a complete file for each.
It is a weaker fit where exceptions are rare, a few a week, and a spreadsheet with a second signature is enough; where an institution wants rates changed automatically without approval, which it deliberately does not do (what agents may propose, and what none may sets out why); or where the core banking system cannot provide a read-only pricing view or accept a rate with an approval number. It does not replace the ALM model or the core. Buyers comparing tools should ask any vendor for the evidence each exception leaves, set out in what each exception file must hold. To see the ladder's first rung on your own past requests, start from Deposit Pricing.
Questions people ask
What is the difference between a deposit pricing tool and an ALM model?
An ALM model measures the institution's interest rate and liquidity position and produces inputs such as the marginal cost of funds. A deposit pricing tool uses those inputs to price individual decisions: rate sheets and exceptions. In the sample, the ALM model's twelve-month marginal cost, 4.41%, is one of the lines in each counteroffer.
Should branches see the agents' counteroffer before the approver decides?
Yes, once the institution is past the shadow rung. A branch manager who can read the counteroffer's lines can prepare the member, and seeing who must decide removes the temptation to promise a rate. In the sample design the branch sees the thread but can never approve her own request.
How many exception requests justify a pricing tool?
There is no threshold, but the case rests on volume and on the cost of slow answers. At a few exceptions a week a spreadsheet and a second signature may suffice; at thousands a month, like the sample credit union's 2,812 in September, the lookups alone occupy a pricing desk and consistency cannot be measured by hand.
Can a pricing tool lower the number of exceptions?
Indirectly. The tool answers exceptions; the rate committee reduces them by moving board rates where exceptions concentrate. In the sample, the agents drafted a proposal to raise the twelve-month certificate's board rate from 4.15% to 4.25%, estimated to remove about 300 exception requests a month.
Who should own the rollout of a deposit pricing tool?
The executive who owns deposit pricing, usually in treasury or retail, with the pricing manager running the ladder and internal audit observing the replay. The CFO or another senior officer should own the matrix as checker, because the matrix, not the tool, decides who may approve what.