Dynamic deposit pricing: what agents may propose, and what none may

Dynamic deposit pricing is the practice of setting or adjusting deposit rates from live data, such as competitors' offers, the cost of other funding and a model of how depositors respond, instead of only from a weekly rate sheet with exceptions granted by phone. Software can now produce such a price in seconds. The harder decision for a bank or credit union is who sets it: an algorithm that publishes rates by itself moves the decision away from the people the board's pricing policy names. Botminds' Deposit Pricing takes the other route. Its agents read the offer, the relationship, the same-term funding curve and a retention estimate and propose a cited counteroffer; they never approve, never change the authority matrix and never use protected characteristics, and a named approver who did not ask decides.

The screens on this page show sample data on a fictional institution, Norrell Federal Credit Union, a $6.8 billion credit union with 38 branches, as it runs through the solution in October 2026.

What is dynamic deposit pricing, and where does it stop?

Dynamic deposit pricing covers three different things that vendors and banks often run together, and a buyer should separate them before comparing anything. The first is a rate sheet that changes more often, driven by market data rather than a calendar. The second is an individual price for each depositor, computed from the relationship, the competing offer and a model of whether the money will stay. The third is automated negotiation, in which software makes and revises offers to the depositor directly.

The first two are pricing questions. The third is a delegation question, because whoever negotiates is deciding. Each step from the first to the third moves a decision closer to the software and further from the person a pricing policy names, usually a deposit pricing manager, a treasurer or a rate committee. That is where dynamic deposit pricing should stop, and where a buyer should ask a vendor to show, on the screen, who decides each price.

Deposit Pricing sits in the second category with the decision held back. It computes an individual counteroffer for each exception request and drafts board-rate proposals from the month's exceptions, but every price that reaches a member, and every change to the rate sheet, is decided by a named person.

Can deposit rates be set automatically? Three designs

Deposit rates can be set automatically; nothing in federal deposit regulation forbids software from publishing a rate. What the rules govern is what is disclosed, and, for an institution that is not well capitalized, how high the rate may go. Truth in Savings requires the disclosed terms to be the terms of the account, and the FDIC's interest rate restrictions cap what a less than well capitalized bank may pay (FDIC national rates and rate caps explains the arithmetic). Who may set a rate is left to the institution's own policy, and that is the real choice.

The left column is faster and, for a digital-only bank repricing a single savings product, may be the right design. For a branch network where exceptions run to thousands a month and each one is a conversation with a member, it moves authority to whoever configures the algorithm. The sample credit union sees about 2,800 exception requests a month across 140 rate products; the decision on each still belongs to a branch manager, the Deposit Pricing Manager or the rate committee, depending on its size.

Eight agents, eight limits: what to ask a vendor to show

The useful document to request from any vendor is not a feature list but the matrix above: for each automated component, what it reads, what it produces and what it may never do. A limit that is not written down is a limit nobody can test. The two that matter most are the ones that keep authority where the policy puts it: the Policy agent cannot approve or change the matrix, and the Disclosure agent cannot run before an approval exists.

Some limits look small and are not. The Offer agent never names the competing institution on anything the member sees, because a disclosure or a thread visible at the branch is not the place to advertise a rival. The Relationship agent, when the core banking system does not answer, stops and says so rather than pricing on a partial view. The Funding agent states the time of every rate it uses, so a counteroffer priced off a stale FHLB sheet is visible as such.

What the Relationship agent reads for pricing, and the fields it never reads

What inputs should a deposit pricing model never use?

A deposit pricing model should never use protected characteristics, or close proxies for them, as inputs: age, sex, race, national origin and marital status, and geography fine enough to stand in for them, such as ZIP code or branch location. It should also not read what pricing does not need: a depositor's tax identification number, date of birth, credit score or income add nothing to the price of a certificate and add risk to every view that shows them.

The reason is not that a federal fair lending statute governs deposit rates; the main ones are written for credit, and exception pricing consistency sets out what that does and does not cover. The reason is that a model fitted to past depositor behavior will learn whatever predicts it, and in a retention model the strongest predictors can be the ones a bank would least want to explain: if older depositors move less, or some neighborhoods have fewer competing branches, the model will find it. A model allowed to use them will offer less to the people least likely to leave, which is a pricing policy nobody chose.

The sample's retention model, RET-3.2, is limited to the offered rate against the outside offer, tenure, products held, balance, term, earlier renewals and direct deposit. It never uses age, sex, race or national origin, marital status, ZIP code or branch location, and those exclusions are printed on the screen where the estimate appears, not in a policy binder.

A retention estimate with its band, its back-test and the inputs it may not use

Who approves an automated rate when an agent proposes it

When an agent proposes a rate, the approver is whoever the authority matrix names for that product, amount and spread, exactly as if a person had proposed it. Automation should not create a new approval path. It should make the existing one faster and better informed, and it should make it impossible to skip.

The matrix itself is the part most often left unguarded. A dynamic pricing system whose administrator can widen authority with one click has moved the decision to the administrator. In the sample configuration a change to the matrix is proposed by one person and checked by another, and only the CFO checks; a pending change to branch authority on short certificates waits on that screen for her, with the agents' estimate of what it would cost.

The authority matrix, and a change that waits for its checker

Is algorithmic deposit pricing allowed, and what the research warns

Algorithmic deposit pricing is allowed: no federal rule prohibits a bank or credit union from computing rates with an algorithm. But three bodies of work say what a bank takes on when it lets one set prices.

The first is economics. In an experiment, Calvano, Calzolari, Denicolò and Pastorello found that pricing algorithms using reinforcement learning "consistently learn to charge supracompetitive prices, without communicating with one another" (American Economic Review, 2020). Brown and MacKay, who document retailers whose software responds automatically to rivals' price changes, show in a model that "the introduction of simple pricing algorithms can generate price dispersion, increase price levels, and exacerbate the price effects of mergers" (NBER working paper 28860; American Economic Journal: Microeconomics, 2023). Neither study is about deposits. Translated to a market where the bank is the buyer of money, a supracompetitive price is a lower rate paid to depositors, set by software that learned to follow its rivals.

The second is supervision of models. The federal banking agencies' revised model risk guidance of April 2026, SR 26-2, treats a statistical estimate such as a retention model as a model, to be validated and tested against outcomes, while placing generative and agentic AI outside its scope and leaving their governance to each bank's own risk management. What SR 26-2 changed is set out in detail on another guide. For a pricing system, the practical reading is that the retention estimate behind a counteroffer needs a back-test and a validator, and the agents around it need controls the bank writes itself; back-testing the chance the money stays takes the first of those apart.

The third is the Financial Stability Board's final sound practices on AI, published in October 2026, which describe agents that pursue goals by their own route and warn: "This creates a risk that they take illegal, unethical, or unauthorised actions without adequate human approval or oversight." The same report says AI "heavily relied upon for credit decisioning, insurance underwriting, or other activities with potentially high impact on customers may warrant greater explainability" (FSB, Sound Practices for Responsible Adoption of AI, 15 October 2026). A rate offered for a member's savings is such an activity. A design in which each line of a counteroffer opens its source is how that explainability reaches the person who decides.

Can AI negotiate with depositors? Not in this design

AI can be built to negotiate with depositors, and Deposit Pricing deliberately is not. In the sample design the agents never speak to the member. They speak to the branch manager and the approver, and the member hears a counteroffer from a person who can explain it, sitting across the desk.

There are three reasons. A negotiating agent decides, because every revised offer is a price, so negotiation puts the agent in the approver's seat. A negotiated rate is a term of the account that has to appear correctly in the Truth in Savings disclosure, and the disclosure should be generated from an approval, not from the last message of a chat. And a negotiating agent learns which depositors accept less, which is the retention-model problem above in its sharpest form. The member's side of the same conversation is in can you negotiate CD rates with banks.

Questions to put to a vendor of dynamic deposit pricing

The questions that separate pricing systems are about authority and evidence, not about the cleverness of the model. Ask each vendor to answer them on its own screens with your own data, and be honest about fit in both directions.

Where Deposit Pricing fits: institutions with branch networks and contact centers, where exception requests arrive from staff sitting with members, and where the pricing policy wants a named approver and a clean file for every one. Where it does not: an institution that wants rates set and changed without people, intraday, on a single digital product. It also does not replace the ALM model or the core banking system; it reads the marginal cost from one and books the approved rate into the other. To see the counteroffer, the limits and the approval on one request, start from Deposit Pricing.

Questions people ask

Is dynamic deposit pricing the same as relationship pricing?

Not quite. Relationship pricing sets a better rate or fee because of the whole relationship, usually by published tiers; dynamic pricing computes the rate from live inputs, which may include the relationship. In treasury services the same idea carries an anti-tying question, covered in relationship pricing in banking.

Do regulators require a person to approve every deposit rate?

No federal rule requires a person to approve each rate. Who may set or approve a rate is a matter for the institution's own policy, which names the people or committee for each product and amount. What examiners review is whether the institution follows that policy and can show it did.

Can an automated system breach the national rate cap?

Only at an institution that is not well capitalized; for a well capitalized institution the FDIC rule sets no cap. A system used at a bank that may fall below well capitalized should know the applicable cap for each product, which the FDIC publishes monthly.

Does SR 26-2 apply to AI agents that price deposits?

The April 2026 guidance places generative and agentic AI outside its scope and applies to traditional statistical models. A retention model behind a pricing recommendation is therefore covered by its principles, while the agents around it are governed by the bank's own controls, which is why the sample's agents cannot approve or change the matrix.

What should automated deposit pricing keep as evidence?

Each input with its source and the time it was read, the recommendation, who decided, the reason code, any override and the signed disclosure. The sample keeps decisions and their sources for seven years; Truth in Savings requires evidence of compliance for at least two.