A pricing exception tool is software that takes requests to price a deposit above the board rate, routes each to the person authorised to decide it, and keeps the evidence of the decision. Most of the value is in the last part. An examiner, an internal auditor or a rate committee asking about an exception wants the same things: what was asked, on what evidence, who approved it under which authority and why, and whether the disclosure the depositor signed and the rate the core booked match the approval. A pricing exception form in an inbox holds the first and sometimes the third. Botminds' Deposit Pricing holds all of them, because the request, the agents' evidence, the approval, the disclosure and the booking happen in one thread, and the file is what the thread leaves.
The file shown here is sample data on a fictional institution, Norrell Federal Credit Union, for one request on October 22, 2026: a member's $350,000 twelve-month certificate, a 4.60% outside offer, and a 4.45% counteroffer approved by the Deposit Pricing Manager.
Anatomy of one exception file, field by field, and what each field proves
Request
On the sample requestOpened 9:52:08 AM by Dana Whitfield, branch manager, Harbor Point; member at the branch; asks 4.60% on a $350,000 12-month certificate; offer letter attached
What it provesWho asked, for what, through which channel, and on what evidence
Offer
On the sample request4.60% APY, 12 months, new money only, like for like; read from the letter, page 1
What it provesShows the match was against a real, comparable offer
Relationship
On the sample request14 of 212 core fields, pricing view only; access log of who looked
What it provesWhat the price relied on, and that nothing else was read
Funding
On the sample requestFHLB 12-month 4.38% read 8:00 AM; brokered 4.52% read 9:30 AM; ALM marginal cost 4.41%
What it provesWhat the price was compared with, and when each rate was read
Retention
On the sample request84% at 4.45% (78–90%); model RET-3.2 and its card
What it provesThe estimate the decision leaned on, and which model version made it
Like requests
On the sample request46 in 90 days, median +30 bp; ask above all 43 approvals, flagged
What it provesConsistency, shown before the decision
Authority
On the sample requestMatrix v14: +45 bp is the rate committee’s; +30 bp is the pricing manager’s; requester excluded
What it provesThat the approver could approve, and the requester could not
Decision
On the sample requestApproved 4.45% at 10:21:07 by Marisol Ortega, checker; reason PX-02; note
What it provesWho decided, when, and why, in a code and in words
Disclosure
On the sample requestTIS-26-10418: 4.45% APY, dividend rate 4.36%; 9 of 9 items; terms equal the approval; delivered 10:24, e-signed 10:26
What it provesThat what the member signed is what was approved
Booking
On the sample requestCore renewed the certificate at 4.45% under approval A-26-10418 at 10:27:31
What it provesThat the rate paid is the rate approved
What is a pricing exception tool, and what it is for
A pricing exception tool replaces the email, phone call and spreadsheet through which most institutions approve rates above their rate sheet. It does three jobs: it takes the request with its evidence, it routes the request to whoever the authority matrix names, and it keeps a complete, unalterable account of what happened. The first two make exceptions faster. The third is what makes them defensible.
The third job is also the one most often skipped. A workflow that routes requests but stores only "approved by M. Ortega, 4.45%" has replaced the email with a database row and kept the gap: nobody can see what the approver was looking at. The test for a tool is whether, a year later, someone who was not there can open one exception and reconstruct the decision from it alone.
What is a deposit rate exception form, and when a form is not enough
A pricing exception form is the document a branch fills in to ask for an exception: the customer, the product, the rate requested, the competing offer and a signature line for the approver. As a request, it works. As evidence, it falls short in three places. It holds what the requester claimed, not what anyone verified. It holds the approver's signature, not what the approver saw. And it stops at approval, so nothing ties it to the disclosure the depositor signed or the rate the core booked.
An exception form and an exception file: the same decision, two kinds of evidence
Pricing exception form: Stated by the requester; the letter, if any, is a separate attachment.
Pricing exception file: Read from the letter, compared term by term, marked verified or unverified.
Pricing exception form: Whatever the approver looked up, nowhere on the form.
Pricing exception file: Each input with its source and the time it was read.
Pricing exception form: A signature; whether the signer could approve is checked later, if at all.
Pricing exception file: Routed by the matrix version in force; the requester cannot approve.
Pricing exception form: A free-text box, often blank.
Pricing exception file: A required reason code, a note, and an override code when the decision differs from the recommendation.
Pricing exception form: Separate systems; matched by hand if anyone checks.
Pricing exception file: Generated from and booked under the approval number, and compared with it.
What is a reason code for a pricing exception?
A reason code for a pricing exception is a short, standard label for why an exception was approved, countered or declined, chosen from a list the institution's policy defines. It makes thousands of decisions countable: how many were matches to verified written offers, how many were relationship retention, how many were declined because the offer could not be verified. A note in words says the rest.
The sample credit union uses three families: PX for an approval or counter, DX for a decline and OV for an override, and one is required on every decision, with an override code as well when the approver's decision differs from the agents'. Marisol Ortega approved the sample request with PX-02, "Matches a verified written offer, within the like-circumstances range", and the note "Verified written offer at 4.60%; counter at the like-circumstances median." A useful list is short. Ten codes that each describe a real reason are better than forty that overlap, because the codes are what the monthly report counts.
The approval dialog: requester, approver as checker, what happens next, reason code and note
Who can approve a deposit pricing exception, and how the tool proves it
A pricing exception can be approved by whoever the institution's authority matrix names for that product, amount and spread, and never by the person who requested it. A tool proves it by keeping the matrix version in force when the decision was made, the tier it applied, and the identity of both requester and approver, and by having refused the requester the option to approve in the first place.
In the sample, matrix version 14 put the 45-basis-point ask with the rate committee and the 30-basis-point counteroffer within the Deposit Pricing Manager's authority; the Policy agent's entry says so, and the requester is excluded on the same line. Changes to the matrix leave their own trail: each is proposed by one person and checked by another, and the change pending in October 2026, branch authority on short certificates, shows its proposer, its reason and its estimated cost while it waits for the CFO. An examiner asking "who could approve this on October 22" gets the answer from the file, not from the current settings.
How do you link an exception to the signed disclosure?
Link an exception to the signed disclosure by generating the disclosure from the approval, not from a template the branch fills in, and by checking before release that its terms equal the approved terms. That makes the approval number the thread that ties the decision, the disclosure and the booking together.
Two checks do most of the work. The rate and APY on the disclosure must equal the approval exactly, and the APY must be recomputed from the rate and compounding, because Truth in Savings counts an APY accurate only within one-twentieth of a percentage point of the correct figure (12 CFR 1030.3(f)(2)). In the sample the disclosure states a dividend rate of 4.36% and an APY of 4.45%, recomputed from 4.3617% compounded monthly, and 9 of 9 required items are checked against 12 CFR 707.4(b), the credit union rule. Then the booking closes the loop: the core renewed the certificate at 4.45% under approval A-26-10418. How each disclosure field maps to its source system is set out in a Truth in Savings disclosure sample, field by field.
The disclosure generated from the approval, with its checks and its delivery
How long should pricing exceptions be kept?
Pricing exceptions should be kept for at least two years to meet Truth in Savings, and longer where an institution's own policy, its examination cycle or other evidence rules require. Regulation DD requires a bank to keep "evidence of compliance" for a minimum of two years (12 CFR 1030.9(c)), and NCUA's Part 707 sets the same minimum for credit unions (12 CFR 707.9(c)). The staff commentary says what that evidence must allow: "Institutions must be able to reconstruct the required disclosures or other actions," and they must keep "information regarding the interest rates and annual percentage yields offered" (Regulation DD, Supplement I, comment 9(c)).
Retention clocks that touch a deposit exception
| What | Minimum | Source |
|---|---|---|
| Evidence of compliance with Truth in Savings, banks | Two years after the disclosure or action was required | 12 CFR 1030.9(c) |
| The same, credit unions | Two years | 12 CFR 707.9(c) |
| Rate and balance information to verify interest paid | As part of the evidence above | Regulation DD commentary, comment 9(c)-3 |
| Evidence of the local market rate cap, banks below well capitalized | The two most recent examination cycles | 12 CFR 337.7(d) |
| Decisions, threads and sources, in the sample configuration | Seven years | Fictional sample credit union’s policy |
| Disclosures, in the sample configuration | Seven years, at least two by rule | Fictional sample credit union’s policy |
The commentary's third point matters for exceptions in particular: "Institutions must retain sufficient rate and balance information to permit the verification of interest paid on an account, including the payment of interest on the full principal balance." An exception rate that lives only in an override field in the core, with no link to who approved it, meets the letter of that sentence and none of its purpose. The file above keeps both the rate and its reason.
How do auditors test exception pricing?
Auditors test exception pricing by selecting decisions and checking each against the policy, and by looking at the population for patterns a sample would miss. The sample tests are about authority and evidence; the population tests are about consistency and cost.
The tests an internal auditor runs on deposit exceptions, and the field each one reads
- The approver had authority
Spread and amount against the matrix version in force on the decision date.
- The requester did not approve
Requester and approver identities on the same file; no officer approving an account they hold an interest in.
- The offer was verified
The offer’s terms read from the attachment, like for like, or the request marked unverified.
- The evidence was current
Funding rates read on the decision date, with their times.
- A reason was given
A reason code on every decision, and an override code where the decision differs from the recommendation.
- The disclosure equals the approval
Rate, APY and term on the signed disclosure against the approval; APY within tolerance.
- The core booked what was approved
The booked rate and approval number against the decision.
- Like requests were treated alike
Across the population: gaps by branch, approver and channel, and outliers above the 90th percentile.
The population tests are where a tool changes what is possible. With exceptions spread across emails, testing consistency means rebuilding a year of decisions by hand; with a decision log, it is a query. How to measure exception pricing consistency sets out the measures.
Thirty-seven minutes on one exception, from the branch's first look to the booking
- Branch looks up the member9:50
- Request to counteroffer, 23 s
- In the approver’s queue24 min
- Review and approval5 min
- Disclosure delivered10:24
- Signed and booked10:27
The audit trail: who did what, when, why and on which evidence, people and agents alike
Choosing a pricing exception tool: questions that separate a form from a file
Ask a vendor of a pricing exception tool to open one past exception and answer an examiner's questions from it, live: what was asked, what the approver saw, who could approve, why this rate, and does the signed disclosure match. A tool that needs a second system, an export and an email to answer is a form with a database behind it.
Then ask the questions that decide fit. Can it read your core banking system's pricing view without reading more than pricing needs? Does it show the time of every market rate it uses? Can the requester be prevented from approving, in the software and not only in policy? Does the matrix itself have a maker and a checker? Is the disclosure generated from the approval, and compared with it? Can the auditor's view be read-only and exportable with member numbers masked? Deposit Pricing answers each on its own screens. It is less suited to an institution whose exceptions are a few a month, where a two-signature form and a monthly check may do, and it works with the disclosure generation and e-signature system an institution already uses rather than replacing it. Getting branches to trust the counteroffer covers the rollout; to see one exception's file opened end to end, start from Deposit Pricing.
Questions people ask
Should declined exceptions be kept as well as approved ones?
Yes. A decline is a pricing decision with the same evidence and authority questions, and declines are half of any consistency test: an institution cannot show that like requests were treated alike if it kept only the approvals. The sample's like-circumstances view counts the three declines beside the 43 approvals.
Does a pricing exception need its own disclosure?
The account needs its disclosure, and the disclosure must show the rate and APY the depositor will actually receive, which for an exception is the approved rate. Generating it from the approval, rather than from the standard rate sheet, is what keeps the two equal.
What is an override code?
An override code marks that the approver's decision differed from the recommendation in front of them, and why, in addition to the reason code for the decision itself. It lets an institution measure how often approvers depart from the agents and whether those departures keep money that the recommendation would have lost.
Can an exception file be changed after approval?
It should not be. A correction should be a new entry that refers to the original, so the trail shows both. In the sample design nothing on the audit trail can be edited or deleted, and deletion at the end of retention runs only as a logged job.
Who should see the exception file?
The approver and requester for their own requests, the pricing desk, compliance, internal audit and examiners, each with what their role needs. The sample masks member numbers in exports, removes the competing institution's name from anything the member or branch sees, and never shows on a pricing view whether an account is under investigation.