Pricing, Interest & Fees

The arithmetic that decides whether a bank earns or loses money

A small-business owner opens her statement at the end of the month and looks at two numbers. The first is the interest her bank paid her on the average balance she kept in her current account — a modest credit of a few dollars. The second is the monthly account fee the bank charged her for running the account — a debit larger than the interest credit. She frowns, does the subtraction, and decides whether to move her business elsewhere. To her, this is a single line of arithmetic. To the bank, it is the visible tip of an entire discipline: the careful, governed, and regulated calculation of every basis point the bank earns, pays, and charges.

Pricing, interest, and fees are the three levers through which a bank turns money into revenue. Pricing is the published set of rates, margins, and charges the bank offers. Interest is the actual cost of money, calculated and accrued daily, posted periodically, and reconciled to the general ledger. Fees are the service charges that customers pay for transactions, penalties, and ancillary services. Together they determine what the customer pays, what the customer earns, and what the bank keeps.

This chapter is the complete study of that discipline in consumer and business banking. It covers how rates are set, how interest is calculated, how fees are designed, how pricing decisions are governed, and how all three are implemented so that the numbers on every statement are accurate, auditable, and defensible.

Learning objectives

By the end of this chapter, you will be able to:

• Distinguish pricing (the published design), interest (the cost of money), and fees (the service charges), and explain how they interact.
• Describe how banks set deposit and lending rates, including the role of the cost of funds, the reference rate, the margin, and the risk premium.
• Outline the major pricing models: fixed, floating, tiered, blended, promotional, relationship, and negotiated.
• Explain interest calculation in depth: principal, rate, time, simple vs compound, compounding frequency, day-count conventions, value dating, and accrual vs posting.
• Describe the major fee types in consumer and business banking and the rationale for each.
• Explain the layered fee model: product default, segment override, account override, and waivers.
• Outline the governance of pricing decisions: committees, policies, controls, regulatory limits, and disclosure rules.
• Describe the regulatory controls that constrain pricing: usury laws, consumer protection, transparency, and conduct rules.
• Outline the systems and architecture that support pricing, interest, and fees, including the data model and integrations.
• Apply the chapter content from the perspectives of business analyst, solution architect, developer, tester, operations, and production support.
• Identify common implementation mistakes, articulate best practices, and answer interview questions on pricing, interest, and fees.

What pricing, interest, and fees are

Three related but distinct ideas sit at the heart of this chapter.

Pricing is the design of the rates, margins, and charges a bank offers. Pricing answers questions such as: what rate do we pay on savings? what margin do we add to the base rate for a loan? what fee do we charge for an out-of-network ATM withdrawal? Pricing is set by the product and treasury teams, governed by committees, and published in the product catalogue.

Interest is the cost of money over time, calculated from the principal, the rate, and the time the money is held or owed. For deposits, interest is what the bank pays the customer. For loans (covered in their own chapter), interest is what the customer pays the bank. Interest calculation, accrual, compounding and posting follow the product contract and applicable law; daily calculation is common but not a universal requirement.

Fees are discrete charges for services and penalties — a fixed monthly maintenance fee, a per-transaction fee, a penalty for early closure. Fees are not tied to time or balance; they are tied to events.

The three interact in the customer's experience. A savings account pays interest, charges a monthly fee, and may waive the fee if the balance exceeds a threshold. A business current account may pay no interest but charge tiered transaction fees. A promotional product may offer a higher rate for six months and then revert to a standard rate, while also waiving fees during the promotion. Understanding each lever, and how they combine, is the discipline of pricing.

Why pricing matters

Pricing is where commercial strategy meets the customer. It matters for four reasons.

Revenue. Pricing is the primary lever of net interest income and fee income. A 10 basis point shift on a multi-billion-dollar book is material; the pricing decision must be deliberate.

Competitiveness. Customers compare rates and fees across banks. A bank that prices too high loses customers; a bank that prices too low erodes margin. Pricing must be calibrated to the market.

Risk. Pricing must compensate for risk. A higher-risk borrower pays a higher rate; a longer-term deposit earns a higher rate. Pricing that does not reflect risk builds losses into the book.

Regulation. Pricing is regulated. Usury laws cap lending rates; consumer protection rules govern fee disclosure; conduct rules require fairness and transparency. Pricing that violates these rules exposes the bank to fines and reputational harm.

How banks set rates

Rate-setting begins with the bank's cost of funds. The cost of funds is the effective rate the bank pays to obtain the money it lends out or holds. For a deposit-funded bank, the cost of funds is the weighted average of deposit rates paid. For a bank that borrows in wholesale markets, it is the wholesale rate plus funding spreads.

To the cost of funds, the bank adds components that reflect the product and the customer.

The final rate paid to a depositor or charged to a borrower is a combination of these components, adjusted for the product's competitive position.

Detailed loan pricing and credit-risk premium modelling are covered in the lending chapters; here we are concerned with how rates are constructed and configured.

Pricing models

Banks use several pricing models, often in combination.

Fixed rate

A fixed rate stays constant for the life of the product or for a defined period. The customer knows exactly what they will earn or pay. Fixed rates are simple, predictable, and easy to communicate. They expose the bank to interest-rate risk if the bank's funding cost moves during the fixed period.

Floating rate

A floating rate moves with a reference rate. The customer's rate is the reference rate plus or minus a margin. When the reference moves, the customer's rate moves. Floating rates pass interest-rate risk to the customer, which suits the bank's balance sheet but introduces variability for the customer.

Tiered rate

A tiered rate pays or charges different rates on different bands of the balance. Tiering is common in savings and business current accounts, where it rewards larger balances without paying the top rate on the entire amount.

Blended rate

For a constant $60,000 balance in the preceding marginal-tier table, simple annual interest is $10,000 × 1% + $40,000 × 1.5% + $10,000 × 2% = $900. The blended nominal rate is $900 / $60,000 = 1.5%. It summarises the tier outcome under those assumptions; an effective annual yield or prescribed APY also requires the applicable compounding and disclosure calculation.

Promotional rate

A promotional rate is a temporary rate offered to attract deposits or borrowers. Promotional rates are configured with a start date, an end date, a promotional value, and the rate that applies after the promotion ends. The system must calculate interest correctly through the transition.

Relationship rate

A relationship rate is a preferential rate offered to customers who hold multiple products or who maintain a defined relationship balance. The rate is configured as a segment override on the standard product, applied based on the customer's relationship score.

Negotiated rate

A negotiated rate is agreed bilaterally between the bank and a customer, typically a large business or high-net-worth individual. Negotiated rates are configured as account-level overrides within governance guardrails, with authorisation and audit.

Interest calculation in depth

Interest calculation is one of the most carefully engineered parts of a banking system, because small errors compound across millions of accounts into material amounts.

Principal, rate, and time

The three inputs to any interest calculation are:

1. Principal — the balance on which interest is calculated. For deposits, this is the balance held. For loans, it is the outstanding principal.
2. Rate — the annual interest rate, expressed as a percentage.
3. Time — the period over which interest is calculated, expressed as a fraction of a year using a day-count convention.

The basic formula for simple interest is interest = principal × rate × time. Compound interest adds eligible interest to the interest-bearing principal at the contractual compounding points, so that subsequent periods earn interest on a larger base.

Simple vs compound interest

Simple interest is calculated only on the original principal. Compound interest is calculated on the principal plus interest previously credited. The compounding frequency — daily, monthly, quarterly, annually — determines how quickly the balance grows.

For the same nominal rate, more frequent compounding produces a higher effective annual rate, because interest is added to the principal more often and begins earning interest itself sooner.

Day-count conventions

The day-count convention defines how time is measured. The three most common conventions in retail and business banking are:

The convention is part of the product definition. Mixing conventions between products, or between the deposit and lending sides of the bank, is a classic source of reconciliation breaks.

Value dating

Value date is the date on which a transaction is effective for interest calculation purposes. It may differ from the transaction date (when the transaction was initiated) and the posting date (when it appeared on the account).

For a cheque deposit, the value date is typically two or three working days after the posting date, reflecting clearing time. For a card transaction, the value date is usually the transaction date. Correct value dating ensures the customer earns or pays interest from the right day.

Accrual vs posting

Accrual is the daily calculation of interest, building up a running balance of interest earned or owed. Posting is the act of moving the accrued interest into the account balance, typically at a defined frequency (monthly, quarterly, at maturity).

The accrual runs daily in batch; the posting runs at the configured interval. Between postings, the accrued interest is visible to operations and reporting but not yet to the customer's available balance. At posting, the accrued amount is added to the principal (for compound products), the accrual resets, and the customer sees the credit.

Interest calculation methods for deposits

Several methods are used to calculate deposit interest, each appropriate to a product type.

Flat balance method

Interest is calculated on the balance at a reference point — typically the end of the day, the end of the month, or the minimum balance during the period. The flat method is simple but can be unfair: a customer who deposits $10,000 on the last day of the month earns the same as one who held it all month.

Daily product method

Interest is calculated each day on that day's balance, and the daily amounts are summed for the period. This method is fair and accurate, and is the standard for modern savings and current accounts.

Average balance method

Interest is calculated on the average daily balance during the period. This method smooths out volatility and is used in some savings and money market products.

Daily product method

Calculate each day's interest from that day's contractual interest-bearing balance and effective rate bands. Under the fictional marginal tiers above, a $60,000 balance has annual simple-interest components of $100, $600 and $200. With Actual/365, that day's unrounded accrual is $900 / 365 = $2.465753…. Whole-balance tiering, different day-count bases and different rounding policies produce different outcomes; configure and test the selected method explicitly.

Fee types in consumer and business banking

Fees are the discrete charges a bank applies for services, penalties, and ancillary products. The major families are:

Consumer fee patterns

Consumer fees are usually simple, transparent, and subject to consumer protection rules. Common patterns include:

• A monthly maintenance fee, waived if the balance exceeds a threshold.
• A number of free transactions per month, with a per-transaction fee above the cap.
• Penalty fees for overdraft, returned direct debits, and late payments.
• Foreign transaction fees on card spending abroad.

Apply the product's actual disclosure, fee, waiver and posting-order requirements under the governing consumer-protection regime. A configurable fee engine does not establish that a charge is permitted.

Business fee patterns

Business fees are usually tiered by volume and value, often negotiated within published bands. Common patterns include:

• A monthly maintenance fee scaled by the size of the business.
• Per-transaction fees tiered by transaction value.
• Channel fees for host-to-host, file-based, and bulk payment services.
• Service fees for treasury, payroll, and reconciliation services.
• Foreign exchange margins negotiated per customer.

Business pricing is more bespoke, reflecting the higher value and complexity of business relationships.

The layered fee model

Like rates, fees are configured in layers.

The effective fee for any transaction is determined by the most specific layer that sets it. A premium customer may have the monthly fee waived by segment override; a specific high-value business may have negotiated per-transaction fees set by account override.

Fee waivers and conditions

Waivers and conditions are the rules under which a fee is not charged, or is charged at a reduced rate.

• Balance-based waiver — the monthly fee is waived if the balance exceeds a threshold.
• Relationship-based waiver — fees are waived or reduced based on the customer's total relationship.
• Volume-based waiver — transaction fees are reduced above a monthly volume.
• Campaign waiver — fees are waived during a promotional period.
• Goodwill waiver — a one-off waiver granted by a relationship manager, with authorisation.

Waivers are configured as conditions on the fee plan; the fee engine evaluates the conditions at the moment of charging. A waiver that is mis-configured either waives fees the bank intended to charge (lost revenue) or charges fees the bank intended to waive (customer complaints).

Governance of pricing decisions

Pricing decisions are governed by committees and policies to ensure they are deliberate, consistent, and compliant.

Pricing policies define the guardrails: minimum margins, maximum waivers, competitive bands, and regulatory limits. Decisions within policy can be made quickly; decisions outside policy require escalation.

Three operating principles make pricing governance effective in practice. First, decisions are evidence-based: every rate or fee change is accompanied by a business case that models the revenue, margin, capital, and risk impact, and by competitive intelligence that places the proposed pricing in its market context. Second, decisions are time-bound: a pricing decision records not only what was decided and by whom, but also when it must be reviewed. A promotional rate is reviewed at its end date; a relationship rate is reviewed annually; a negotiated rate is reviewed at the customer's next credit review. Third, decisions are reversible in design if not in impact: even after a change goes live, the bank can reverse course, but only by creating a new version with a new effective date, not by editing history. This keeps the audit trail intact while allowing the bank to respond to outcomes.

Regulatory controls on pricing

Several regulatory frameworks constrain pricing decisions.

The pricing team must understand these frameworks, and the configuration team must implement controls that enforce them. A pricing decision that violates a usury cap or a transparency rule is not just a commercial error; it is a regulatory breach.

Transparency and disclosure

Customers must be able to understand what they pay and what they earn. Applicable product/jurisdiction disclosure rules can require:

• Prescribed APR disclosure for covered lending products; US Regulation Z generally exempts business-purpose credit, with specified card provisions remaining applicable. See Regulation Z scope and exemptions.
• The applicable deposit yield disclosure, such as UK AER or US APY, with its prescribed assumptions.
• Itemised fee schedules, not bundled into a single opaque charge.
• Change notices at the timing required by law and contract, including applicable exceptions. US consumer-deposit Regulation DD §1030.5 distinguishes changes requiring notice from exceptions such as variable-rate changes.
• Plain-language summary documents (key facts, key terms).

The pricing team designs the rates and fees; the configuration team attaches the disclosures; the channels display them. All three must align so that the customer sees consistent, accurate information.

Systems and architecture

Pricing, interest, and fees are supported by a coordinated set of systems.

In a modern architecture, these systems communicate through APIs and events. The product catalogue publishes rate and fee changes; the interest and fee engines subscribe and refresh; the general ledger receives accounting entries; the statement engine reads the same data the engines produced.

Data model

A simplified data model for pricing, interest, and fees looks like this.

Each entity is normalised, effective-dated where appropriate, and audited. The data model is the contract between the pricing discipline and the systems that execute it.

Consumer and business pricing examples

To make the discipline concrete, consider two examples.

Example 1: Consumer high-yield savings (consumer)

A product aimed at mass-market savers, designed to compete on rate while protecting margin.

Example 2: Business premium current account (business)

A product aimed at mid-market companies, designed to bundle services with tiered fees.

The two products share the same data model but differ in the values and the conditions they embody.

Functional pricing implementation in a bank

The earlier sections explain the concepts. This section turns those concepts into functional banking behaviour. In a real bank, pricing is not one field called rate and another field called fee. It is a controlled chain of decisions: which customer is eligible, which product version applies, which price plan is selected, which rate source is used, which margin is added, which fee plan is linked, which waivers are allowed, which effective date applies, which system calculates the amount, which system posts it, and how the customer and the bank can later prove what happened.

A functional pricing design must answer four questions every time money is priced. First, what is being priced: a deposit balance, loan balance, overdraft usage, card balance, account package, transaction, cash service, statement feed, or channel service? Second, who is being priced: a consumer, sole proprietor, partnership, SME, corporate, non-profit, government body, premium customer, staff customer, or relationship customer? Third, when is it being priced: transaction date, value date, posting date, statement date, billing date, reset date, or maturity date? Fourth, which rule wins when more than one rule could apply?

Functional pricing objects and hierarchy

A bank normally breaks pricing into reusable objects: product price plan, rate table, margin rule, fee schedule, waiver rule, discount rule, campaign rule, relationship rule, override rule, tax rule, posting rule, and disclosure rule. A functional requirement should identify which objects are required, who owns them, which system stores them, which system consumes them, and how they are versioned.

Most pricing defects happen because the system does not know which rule wins. A customer may have product pricing, segment pricing, relationship pricing, campaign pricing, staff pricing, negotiated pricing, and account-level overrides at the same time. The functional design must define priority and explain the selected price.

Functional setup

For deposits, interest setup normally includes product code, currency, balance basis, rate table, day-count convention, accrual frequency, posting frequency, compounding rule, rounding rule, tax treatment, minimum balance rule, tier or band rule, and closure treatment. For lending, setup includes principal basis, outstanding balance, reference rate, margin, reset frequency, repayment schedule, accrual method, penalty interest rule, overdue interest rule, capitalization rule if allowed, rounding, amortisation interaction, and statement display.

A functional fee rule should define fee item, triggering event, charging frequency, amount or formula, currency, tax applicability where relevant, waiver rules, reversal rules, refund rules, posting account, revenue account, customer display wording, and dispute handling. If the fee is event-based, the event definition must be precise. If the fee is periodic, the period must be precise. If the fee is volume-based, the counter must be precise.

Functional data flow

A typical pricing journey starts in origination or servicing. The channel asks which products and prices are available for the customer, segment, country, currency, and value date. The product catalogue returns eligible product versions and linked price plans. The pricing or interest engine calculates rates, fees, waivers, or indicative costs. The channel displays customer-facing price information and required disclosures. If the customer accepts, the account or contract stores product version, price plan, rate, margin, fee plan, waiver, and accepted document version.

During operation, transactions, balances, time, and events trigger calculations. The interest engine accrues interest daily or by configured frequency. The fee engine assesses event or periodic fees. The billing platform may invoice business fees. The core or accounting engine posts interest and fees to customer accounts and general ledger accounts. Statements display the result. Data warehouse and reporting systems consume the pricing outcome for profitability, revenue, complaints, and control reporting.

Worked functional calculations

A fictional savings account pays 3.60% nominal annually on its cleared closing balance, using Actual/365 and monthly crediting. At a constant balance of 100,000 for 30 days, simple interest before tax is 100,000 × 0.036 × 30 / 365 = 295.89, rounded to cents. The unrounded daily accrual is 100,000 × 0.036 / 365 = 9.863013…. Accumulate and credit according to the contractual rounding policy; rounding every daily amount first can produce a different monthly result.

Suppose a tiered savings product pays 2 percent on the first 50,000, 3 percent on the next 50,000, and 4 percent above 100,000. A customer with 120,000 should not automatically receive 4 percent on the full balance unless the product is configured as whole-balance tiering. Under marginal tiering, annual simple interest is 50,000 × 2% + 50,000 × 3% + 20,000 × 4% = 3,300. The blended nominal rate is 3,300 / 120,000 = 2.75%, before any compounding or prescribed yield disclosure calculation.

A fictional business account charges 0.50 per eligible domestic payment after 500 free monthly items. If it sends 620 eligible payments in the calendar month, excess items are 620 − 500 = 120 and the fee is 120 × 0.50 = 60.00. If the contract counts one bulk file as one item, rather than each instruction, the fee can differ. Record the contractual billable-event definition and deduplicate retries.

Functional review catalogue for pricing rules

For salary waiver, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence. The business analyst should define the rule in measurable terms so a developer does not need to interpret policy language. The product owner should confirm why the price exists and whether it is meant to recover cost, reward behaviour, manage risk, attract balances, retain a customer, or discourage expensive servicing. The tester should prepare normal, boundary, negative, reversal, migration, and historical value-date cases. Operations should know how to explain the outcome, and production support should be able to reconstruct the selected price from stored product version, event reference, balance, rate table, fee schedule, waiver, override, and posting reference.

For new money promotional rate, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For tiered savings interest, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For whole-balance tiering, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For marginal-balance tiering, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For monthly account fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For ATM allowance fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For bulk payment package, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For statement feed fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For cash handling fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For foreign-currency transaction fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For negotiated corporate fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For relationship-balance discount, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For staff pricing, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For student conversion pricing, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For overdraft authorised interest, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For overdraft unauthorised interest, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For late payment fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For card replacement fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For early term-deposit breakage, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For loan prepayment charge, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For merchant settlement fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For API access fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For host-to-host file fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For returned item fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For manual repair fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For fee refund, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For fee reversal, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For campaign expiry, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For rate reset, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For reference-rate fallback, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For multi-currency fee posting, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For tax withholding on interest, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For package counter reset, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For account closure fee handling, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For mid-cycle opening fee, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For dormant account charging, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For customer complaint correction, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For GL reconciliation, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

For pricing data warehouse reporting, the functional design must identify the trigger, input data, rule priority, effective date, calculation basis, customer-facing wording, posting behaviour, accounting treatment, reporting treatment, exception handling, and support evidence.

Functional readiness checklist

A Pricing, Interest and Fees implementation is not ready until product default pricing exists, segment and relationship rules are defined, negotiated pricing boundaries are approved, rate tables are effective-dated, fee items have trigger events, waivers have measurable conditions and expiry, customer disclosures match system behaviour, accounting mappings exist, reports receive product and price identifiers, tests cover arithmetic and rule priority, operations has servicing instructions, support has diagnostic views, and reconciliation proves posted amounts match expected amounts.

The final test is simple: can the bank safely promise a price, calculate it, post it, explain it, reverse it, report it, and defend it? If yes, the functional pricing design is strong. If any one of those verbs fails, the chapter is no longer academic; it has found a real implementation gap.

Business rules and validation

Pricing, interest, and fees operate under many business rules. The most important are:

• A rate cannot exceed the regulatory cap (usury limit) for the product type.
• A fee cannot be charged without a configured fee plan.
• A waiver cannot be granted without a configured condition or explicit authorisation.
• An interest accrual must use the rate in force on the accrual date (effective-dating).
• A fee change cannot be applied retroactively without an authorised exception.
• A promotional rate must have a defined end date and a successor rate.
• A negotiated rate must sit within governance guardrails and be authorised.
• Interest posted must reconcile to interest accrued in the period.
• Fees charged must reconcile to the fee plan and any waivers applied.

Validation rules are encoded in the interest engine, fee engine, and configuration workflows, and are tested exhaustively.

Risks and controls

Each risk has a preventive control, a detective control, and an audit trail.

Exceptions and operational reality

Pricing and charging encounter exceptions daily. Common ones:

• Rate applied to wrong product. A rate change is applied to a broader set of products than intended, requiring backdated correction.
• Promotional rate did not revert. A promotion ended but the system continued to apply the promotional rate; correction requires recalculation for affected accounts.
• Fee charged despite waiver. A waiver condition was not evaluated, leading to customer complaints and fee refunds.
• Negotiated rate outside guardrails. A relationship manager agreed a rate outside their authority; escalation and re-pricing required.
• Interest reconciliation break. Accrued interest does not match posted interest; investigation finds a failed accrual job or a rate gap.
• Disclosure mismatch. A fee was changed without updating the disclosed fee schedule; re-disclosure required.
• Goodwill waiver dispute. A goodwill waiver was granted but not recorded; revenue assurance flags the gap.

Each exception has a defined process, an authorisation level, and an audit trail.

Reconciliation and reporting

Pricing, interest, and fees are reconciled at multiple levels.

• Interest reconciliation. Daily accruals sum to the period's posted interest; posted interest reconciles to the general ledger's interest expense (deposits) or income (loans).
• Fee reconciliation. Fees charged per the fee engine reconcile to fee income in the general ledger and to fee revenue reports.
• Pricing reconciliation. Configured rates reconcile to rates actually applied; configured fee plans reconcile to fees actually charged.
• Regulatory reporting. Interest paid to customers is reported for tax purposes; fee income is reported in financial statements; pricing data is reported for conduct and transparency reviews.

Reconciliation is the daily proof that pricing discipline is working. A break is a signal that something in the configuration, the engine, or the integration is wrong and must be found and fixed.

Business Analyst perspective

A business analyst on pricing focuses on translating commercial intent into rules.

• Requirement capture. Convert a pricing proposition into the rate plans, fee plans, and conditions the system consumes.
• Edge case definition. Specify behaviour at tier boundaries, promotion end dates, waiver thresholds, and minimum balance conditions.
• Traceability. Trace every pricing rule to a configured attribute and a test case.
• Impact assessment. When a rate or fee changes, assess which products, segments, and accounts are affected.
• Disclosure alignment. Ensure the disclosures match the configured rates and fees, with no gap between what is configured and what is communicated.

The BA's craft is precision, because a vaguely specified pricing rule becomes a defect that affects every customer of the product.

Solution Architect perspective

An architect designing pricing, interest, and fee systems thinks about flexibility, correctness, and scale.

• Effective-dated modelling. Ensure rates and fees carry effective dates and queries return the in-force value at any date.
• Engine separation. Separate the interest engine, fee engine, and pricing decision engine so each can evolve independently.
• Performance. Interest accrual runs daily across millions of accounts; it must complete within the batch window and be restartable.
• Reconciliation hooks. Every engine produces a reconciliation file; breaks are surfaced immediately.
• Event model. Publish RateChanged, FeeChanged, InterestAccrued, FeeCharged events so downstream systems react without coupling.
• Guardrails as data. Encode regulatory caps and policy limits as data the engines read, so changes do not require code releases.

The architect's hardest job is to make the engines flexible enough to support the bank's pricing ambitions for decades while keeping them correct enough to reconcile to the penny every night.

Developer perspective

A developer implementing pricing, interest, and fee engines cares about correctness and precision.

• Money handling. Use decimal types or integer minor units; never floating point. Round only at defined points using the configured rounding rule (typically banker's rounding).
• Day-count correctness. Implement each convention explicitly; test against independent calculations.
• Effective-dated queries. Implement queries that return the in-force value at a given date.
• Idempotency. Accrual and posting runs must be idempotent, so a retry does not double-accrue or double-post.
• Restartability. A failed accrual must be restartable from the last successful point, with no double-counting.
• Audit. Every rate, fee, waiver, accrual, and posting writes to an append-only audit log.
• Tests. Unit tests cover each convention and rounding rule; integration tests cover end-to-end accrual, posting, and reconciliation.

The developer's discipline is to make the arithmetic invisible: every calculation correct, every edge case handled, every rounding decision documented.

Tester perspective

A tester validating pricing engines attacks the boundaries and the conventions.

• Day-count conventions. For each convention, compare the system's calculation to an independent calculation across a range of principals, rates, and periods.
• Compounding. For each frequency, verify the effective annual rate matches an independent calculation.
• Tiered interest. At each tier boundary, verify the correct rate applies to the correct portion of the balance.
• Promotional transitions. Before, during, and after a promotion, verify the correct rate applies on each day.
• Fee evaluation. For each fee type, verify the correct fee is charged under each condition and waiver.
• Effective-dating. On the day before, the day of, and the day after a rate change, verify the correct rate applies.
• Reconciliation. After a synthetic day, verify accruals sum to postings and postings reconcile to the ledger.

The tester's value is in finding the defects the developer did not anticipate — usually at the boundaries between rules and edge cases.

Operations perspective

Operations runs the pricing book day to day.

• Rate changes. Apply approved rate changes correctly, with effective dates and audit.
• Fee changes. Apply approved fee plan changes, ensuring waivers and conditions are updated.
• Daily accrual. Monitor the nightly accrual run; investigate failures; ensure restartability.
• Reconciliation. Review daily reconciliation reports; investigate breaks; close them within SLA.
• Customer disputes. Investigate disputes over interest or fees; apply refunds where appropriate, with authorisation.
• Goodwill waivers. Process goodwill waiver requests within authority; record for audit.

Operations is where the pricing discipline meets the customer. The best systems make operations' job easier — clear reconciliations, clear exceptions, clear explanations.

Production support scenarios

Production support handles incidents on the pricing engines.

• Scenario 1: Accrual failure. The nightly accrual job failed halfway. Support identifies the failure point, restarts the job with idempotency, and confirms reconciliation.
• Scenario 2: Rate applied late. A rate change was configured with the wrong effective date; accounts accrued at the old rate for several days. Support recalculates the affected period and posts correcting entries under change control.
• Scenario 3: Fee charged in error. A fee plan was applied to the wrong product; customers were charged in error. Support identifies the affected accounts, reverses the fees, and communicates with customers.
• Scenario 4: Waiver ignored. A waiver condition was not evaluated due to a configuration error. Support fixes the condition, identifies affected transactions, and processes refunds.
• Scenario 5: Reconciliation break. Posted interest does not reconcile to accruals. Support traces the break to a failed posting job or a rate gap, corrects, and reconciles.
• Scenario 6: Promotional rate did not revert. The promotion end date was mis-configured; customers continued to receive the promotional rate. Support corrects the configuration, recalculates from the intended end date, and communicates with affected customers.

Production support lives by runbooks, observability, and disciplined change.

Pricing strategy: where interest and fees meet the market

Beneath every rate and fee sits a strategic choice, and the mechanics this chapter describes serve choices made at a higher level that is worth making explicit.

Deposit pricing balances three pressures: the funding value of the balance, the market's price for that balance, and the franchise's pricing power. A bank with strong primary relationships prices below the marginal market rate and keeps balances anyway, monetising trust and convenience; a bank without them buys balances at the margin and watches them leave when the price moves. Tiering, relationship pricing and promotional rates are the instruments, and each carries a known pathology: tiers that most customers cannot reach, relationship discounts nobody understands, promotions that train customers to wait for the next one. Lending pricing balances risk, funding cost, capital consumption and competition, expressed through the risk-based pricing the credit chapters describe, with the pricing engine as the instrument that makes the strategy executable at scale.

Fee strategy is more constrained and more scrutinised. Cost-recovery pricing ties fees to the cost of the service but still requires applicable legal, contract and conduct review; value pricing charges what the service is worth to the customer and demands conduct confidence; penalty-shaped fees, which price customer mistakes, are the most legally fragile and the most reputationally expensive, and many jurisdictions have capped, reformed or litigated them into narrow bounds. The strategic discipline that survives is transparency: prices a customer can find, understand and compare, applied exactly as published, with the machine that executes them auditable to the published schedule. Pricing strategies built on customer inattention have a shrinking legal shelf life, and pricing infrastructure built for transparency never needs to be apologised for.

Concessions, waivers and negotiated pricing

Between the published price and the charged price sits the world of concessions, and it needs machinery as disciplined as the rate card itself.

The concession types are familiar: the waived monthly fee for a maintained balance, the discounted rate for a bundled relationship, the negotiated margin for a business that brings its treasury, the goodwill waiver for a first mistake, the retention offer for a customer halfway out the door. Each type has an authority model: which concessions the product grants automatically by rule, which staff may grant within limits, which require management approval, and which are simply not available, and the pricing engine must enforce the model at the moment of charging, not reconstruct it at month end. Automatic concessions are the safest because they are rules: the waiver that fires for every qualifying customer equally is a pricing feature; the waiver granted at a branch officer's discretion is a fairness risk and a leakage channel unless it is bounded, recorded and reviewed.

Governance measures keep the world honest: concession volumes and values by type and granter, leakage against the rate card, and the distribution of discretionary concessions across customer demographics, because discretionary pricing is where unconscious discrimination hides and where fairness testing earns its keep. The commercial discipline closes the loop: every concession family has an owner who knows its cost and can state its return, retention value, relationship depth, complaint avoidance, and concessions that cannot state their return are retired at review. Negotiated pricing for business customers formalises all of this into pricing agreements: documented, dated, approved, stored with the relationship, and executed by the engine so that the invoice matches the agreement line for line, which is what the customer's finance team reconciles and what the bank's revenue assurance must prove.

Interest and fee disclosure: the transparency obligations

Almost everything in this chapter is visible to customers through disclosure, and the disclosure obligations are detailed enough to be a design domain of their own.

Pre-contract disclosure sets expectations before commitment: standardised information documents for accounts, rate sheets for deposits and loans, fee schedules in agreed formats, presented early enough to support comparison and in language regulators test for comprehension. In-life disclosure keeps the picture current: statements that show interest charged and paid with rates applied, fee advices that precede or accompany charges as local rules require, and notifications when prices change, with notice periods that let a customer act before the new price bites. Trigger-based disclosure fires at the moment of risk: overdraft warnings, high-cost credit alerts, and the increasingly common obligation to warn before a fee is incurred when avoidance is still possible.

Disclosure should use governed pricing inputs, but a shared source does not eliminate discrepancies: stale versions, mapping errors, rounding, eligibility and timing can still create customer harm. Independently reconcile the disclosed schedule, actual charged amounts and contract population, including corrections and concessions. Generation from configuration reduces manual drift; it does not replace testing or remediation.

Measuring pricing performance: margin, leakage and conduct

Pricing is complete only when it is measured, and three measurement families tell the whole story.

Margin measurement tracks whether prices deliver their economics: net interest margin by product and segment, fee income against expectation, and the contribution of each pricing element to product profitability. Its purpose is strategic feedback, answering whether the deposit spread justifies the acquisition cost, whether the fee structure earns what the service costs, and where repricing is owed. Leakage measurement tracks the gap between the rate card and reality: unapplied fees, concessions beyond policy, waivers granted and never reviewed, errors refunded, and the revenue that evaporates in operational gaps. Leakage is the pricing function's quality metric, and mature banks measure it as deliberately as they measure income, because a two percent leakage rate on a large book is a material number hiding in thousands of small mercies.

Conduct measurement tracks whether pricing treats customers fairly in fact: the distribution of fees across customer groups, the incidence of penalty-type charges on vulnerable populations, complaint rates per priced event, and the outcomes of fairness testing on discretionary pricing. Conduct measures increasingly drive supervisory conversations, and they drive the pricing function's own redesigns: the fee restructured because its incidence was regressive, the alert introduced because customers were surprised, the cap applied because a small group was paying a large share. Pricing that is measured on all three families, margin, leakage and conduct, is pricing the bank can grow, defend and be proud of, which is the standard this chapter's machinery exists to serve.

Rate regime change: negative rates, inflation shocks and structural shifts

Pricing machinery earns its keep on ordinary days, but it is tested by regime change, and the pricing chapters would be incomplete without the discipline of extremes.

Negative interest rates, once considered a theoretical curiosity, became lived reality in several markets, and they stress every assumption a pricing engine holds: interest that flows from depositor to bank, floors that must be configured where law or policy forbids charging ordinary savers, tier structures that exempt small balances while charging institutional ones, and customer communication of a concept that feels inverted. Engines that assumed rates are always positive discovered their assumptions in production; engines built with signed arithmetic and configurable floors absorbed the regime as configuration. The lesson generalises: every assumed constant in pricing design should be examined for what happens when it inverts.

Inflation and rate shocks stress a different dimension: speed and fairness. When reference rates move monthly or faster, administered rates must be re-governed at the same cadence, notice periods and their waivers must be applied lawfully, promotional pricing collides with market reality, and the gap between what loyal customers earn and what new customers are offered becomes a fairness story that regulators and journalists both follow. Structural shifts complete the catalogue: reference-rate transitions, when a benchmark is retired and thousands of contracts must move to a successor rate, are among the largest pricing-change exercises a bank ever runs, executed as configuration with legal notices, fallback provisions and customer communication at portfolio scale. Regime change is not an edge case in a pricing function's life; it is the exam the machinery was built for, and the grade is public.

Deposit-side pricing in depth: interest on credit balances

Most pricing attention flows to what the bank charges; what the bank pays deserves equal engineering, because deposit-side pricing is where the funding economics and the customer promise meet.

The structural choices mirror the lending side with inverted incentives. Tiering by balance rewards the balances the bank values most, but every tier boundary is a customer-facing cliff that invites gaming, splitting balances, timing movements, and a fairness question about who can reach the better tiers. Relationship pricing rewards depth across products, and its configuration must define depth honestly, countable, stable, and explained, because a relationship bonus that evaporates when a product matures is a betrayal the customer discovers at statement time. Promotional rates acquire balances at a premium, and their machinery, eligibility windows, bonus periods, end-date communication, decides whether promotion builds a book or merely rents one, which is why the end-of-promotion journey, what the customer is told and offered when the bonus expires, is designed as carefully as the acquisition campaign.

The accounting and control side is equally structured: interest expense is a first-class ledger flow with accrual and payment disciplines, rate changes carry notice obligations in many markets, and the deposit pricing committee's decisions, rates by product and tier, with their effective dates and rationales, are governed records examined by finance, audit and, increasingly, conduct supervisors asking whether loyal customers are systematically paid less than new ones. The fair-value question embedded in that examination, does the bank's pricing reward loyalty or exploit inertia, is answered not in policy statements but in the rate history of the book, which is why deposit pricing data is kept, trended and reviewed with the same seriousness as credit losses.

Stress-testing the pricing engine: resilience and failure modes

A pricing engine fails differently from other systems: it rarely stops, it merely computes wrongly, confidently and at scale, which is why pricing resilience is a discipline of correctness under stress rather than mere availability.

The failure catalogue starts with data failures: reference rates that fail to publish, feed staleness that goes unnoticed, market-data formats that change unannounced, and each has a designed response, last-good-value with alerting, fallback sources, and rate-set procedures that switch to governed manual decision with evidence, because a missing reference rate must never mean a guessed one. Volume stress is the second family: repricing events that touch millions of accounts, end-of-period accruals compressed into batch windows, and rate-change days when computation, notice generation and customer contact all peak simultaneously, tested in advance at realistic scale because pricing defects at volume are remediations at volume.

The human failure modes complete the catalogue: the mis-keyed rate caught by maker-checker or not, the effective date set wrong so that a change backdates, the wrong book migrated to a new structure, and the change deployed without its notice letters. The defences are the chapter's recurring trio, segregation of duties, automated validation against sanity bounds, and rehearsed rollback, plus the assurance layer that samples computed results independently every cycle. The pricing engine's resilience metric is not uptime; it is the count of customer-affecting pricing errors per period, driven toward zero by design and by the honest investigation of every one that survives.

Real banking implementation examples

A few real-world illustrations show the discipline in action.

A bank re-prices its savings book after a central bank rate cut. The pricing committee approves a 25 basis point reduction across standard savings products, effective Monday. The configuration team creates new versions of each rate plan, effective-dated from Monday. The interest engine picks up the new versions at the next accrual run; existing accounts accrue at the new rate from Monday, while historical accruals remain at the old rate. Statements and customer communications reflect the change. The whole exercise, affecting millions of accounts, completes in days because pricing is data.

A bank launches a promotional term deposit campaign. The marketing team defines a promotional rate of 5 percent for a 12-month term, available for 30 days. The configuration team creates a promotional rate plan with the campaign window, attaches the disclosures, and configures the eligibility. Origination reads the new plan; the interest engine accrues at the promotional rate. At the campaign end, the plan is restricted; existing deposits continue at the promotional rate to maturity.

A bank introduces relationship pricing for premium customers. Customers with a total relationship balance above $250,000 receive a 0.25 percent preferential rate on savings and a waiver on monthly account fees. The configuration team creates a segment override, with the relationship score as the condition. The interest engine applies the override at accrual; the fee engine applies the waiver at charging. The relationship team monitors uptake and margin impact.

A bank overhauls its business fee schedule to be more transparent. The existing schedule bundles fees into a single monthly charge; the new schedule itemises each fee. The configuration team redefines the fee plan with itemised fees, updates the disclosures, and coordinates with channels to display the new format. Existing accounts are migrated; customers are notified; the change is rehearsed in a sandbox before launch. The migration touches the fee engine, the statement engine, the channels, and the disclosure library.

Common implementation mistakes

• Floating-point money. Using floating-point arithmetic for interest and fees introduces rounding errors that compound into real money over millions of accounts.
• Mixing day-count conventions. Applying different conventions across products without reconciliation produces breaks between the deposit and lending books.
• Missing effective-dating. Changing a rate without preserving its history breaks historical interest calculations and audit.
• Hardcoded rates and fees. Embedding pricing in code rather than configuration makes every change a release and creates inconsistency risk.
• Ignoring value dates. Calculating interest from the posting date rather than the value date over- or under-pays customers systematically.
• Weak idempotency. Accrual and posting runs that double-count on retry produce material errors and customer harm.
• Disclosure drift. Letting disclosures fall out of sync with configured rates and fees creates regulatory exposure.
• Override abuse. Account-level negotiated rates or fee waivers without governance produce revenue leakage and unfairness.
• No reconciliation. Without daily reconciliation, errors accumulate silently until they become incidents.
• One engine for everything. Combining interest, fees, and pricing decisions into one component makes the system hard to evolve and test.

Best practices

• Decimal money, never floats. Use decimal types or integer minor units; round only at defined points using the configured rule.
• Effective-date everything. Every rate, fee, and condition carries effective dates; historical queries return the in-force value.
• Separate the engines. Keep the interest engine, fee engine, and pricing decision engine separate, so each can evolve independently.
• Configuration over code. Rates, fees, conditions, and caps are data, read at runtime.
• Reconcile daily. Accruals to postings; postings to ledger; configured rates to applied rates; configured fees to charged fees.
• Encode regulatory caps as data. Usury limits, fee caps, and disclosure rules are data the engines read, not code.
• Test conventions and boundaries. Each day-count convention, each tier boundary, each promotion transition, each waiver condition, tested explicitly.
• Disclose at configuration time. When a rate or fee is configured, the disclosure is updated in the same change, under the same approval.
• Govern overrides. Negotiated rates and goodwill waivers are authorised within guardrails, recorded for audit, and reviewed periodically.
• Observability. Daily accrual duration, reconciliation breaks, fee revenue, and waiver volume are visible on dashboards.

Summary

Pricing, interest, and fees are the three levers through which a bank turns money into revenue. Pricing is the published design; interest is the cost of money over time; fees are the discrete charges for services and penalties. Together they determine what the customer pays, what the customer earns, and what the bank keeps.

We have walked through how rates are set from the cost of funds and the reference rate, the major pricing models (fixed, floating, tiered, blended, promotional, relationship, negotiated), and interest calculation in depth (principal, rate, time, simple vs compound, compounding frequency, day-count conventions, value dating, accrual vs posting). We have examined the major fee types in consumer and business banking, the layered fee model, waivers and conditions, the governance of pricing decisions, and the regulatory controls that constrain them. We have outlined the systems and data model that support pricing, the risks and controls, the exceptions and reconciliations, and the perspectives of business analyst, solution architect, developer, tester, operations, and production support.

The bank that masters pricing, interest, and fees earns the right rate, charges the right fee, and reconciles every penny every night, across millions of customers. The bank that does not, leaks revenue, mishandles customers, and attracts regulatory findings. The choice, made in every rate plan, every fee plan, every accrual, and every reconciliation, is consequential and enduring.

Key takeaways

• Pricing is the design; interest is the cost of money over time; fees are discrete charges for services and penalties.
• Rates are built from the cost of funds, reference rate, margin, risk premium, liquidity premium, operational cost, and capital charge.
• The major pricing models are fixed, floating, tiered, blended, promotional, relationship, and negotiated; most products combine several.
• Interest calculation depends on principal, rate, time, compounding frequency, and day-count convention; small errors compound into material amounts.
• Value dating determines the effective date for interest; ignoring it systematically over- or under-pays customers.
• Accrual runs daily; posting moves accrued interest into the balance at a defined interval; reconciliation compares the two.
• Fees are layered: product default, segment override, account override; waivers are conditions evaluated at charging time.
• Pricing is governed by committees and policies, and constrained by usury laws, consumer protection, transparency, conduct, FX, and tax rules.
• The systems are the product catalogue, interest engine, fee engine, pricing decision engine, treasury/ALM, ledger, statements, tax, and regulatory reporting.
• Decimal money, effective-dating, separate engines, daily reconciliation, and exhaustive testing of conventions and boundaries are what separate a pricing system that scales from one that does not.

Recalculate the customer outcome before changing a price

A fictional deposit pays 2% on the first 50,000, 3% on the next 50,000 and 4% on the remainder. At a constant balance of 120,000, one year of simple marginal-tier interest is 50,000 × 2% + 50,000 × 3% + 20,000 × 4% = 3,300, a 2.75% blended nominal rate. This is not automatically its annual percentage yield: compounding and the prescribed disclosure method matter. Separately, a 3.6% nominal rate compounded monthly gives (1 + 0.036/12)^12 − 1 = 3.660% annual effective yield, rounded to three decimals. Actual accruals depend on the contractual balance history and calendar.

For lending, APR is a jurisdiction-defined cost measure, not simply nominal interest plus every fee. Which charges enter the finance charge and which cash-flow conventions apply depend on the product and regime. US Regulation Z, 12 CFR 1026.22, prescribes the closed-end APR determination and applicable tolerances. For consumer deposits, Regulation DD, 12 CFR 1030.7, addresses interest calculation, permitted balance methods, compounding/crediting and related rules; use its applicable APY disclosure provisions separately. An SME credit APR illustration is not proof that all business-purpose loans fall under Regulation Z.

Record the agreed price version, customer eligibility, waiver authority, notice and effective date. When correcting a rate error, compute the intended and actual cash flows from the same balance history, post an approved adjustment, reconcile the interest-expense or income effect, and explain compensation to the customer. A correct new rate does not repair past underpayment.