How Fineract fixed deposit rate charts set the rate on new accounts
A product team that offers tiered deposit rates by term and amount needs to know, before any account opens, exactly which rate a new fixed deposit receives. In Apache Fineract, that answer comes from a rate chart attached to the deposit product, not from a single rate typed onto the product. A rate chart is a set of rate slabs, each tied to a term range and often an amount range, along with validity dates that decide which chart is in force on the day an account is opened. A flat product rate is usually enough when every customer earns the same return. Teams need a chart when the rate must change with how long money is locked up or how much is deposited, or when a new rate schedule must take effect on a set date without rewriting existing products.
This page covers how to build the chart, attach it to fixed and recurring deposit products, and check the rates that new accounts actually receive. The Fineract README and the platform documentation are the reference for object names, fields and lookup behavior, and the exact rules for matching a term or amount to a slab, for handling overlapping or gaps in slabs, and for which chart applies when several exist must be confirmed against the 1.15.0 documentation before the design is signed off. Confirm these points in a test tenant with your own slab layout, because a misread slab boundary changes the rate paid on every new deposit.
Before building anything, the team should write down the slab table, the boundary rule (inclusive or exclusive at each end), the validity window for each chart version, and who approves a change. These decisions drive the verification step, which is where most errors are caught: create one test account at each slab boundary and at each edge of the validity window, then compare the rate Fineract applies with the approved table. Ask the implementation partner or the vendor to confirm the boundary behavior in writing, so the test cases reflect the platform's real behavior rather than an assumption.
Which rate chart design fits each deposit product
This table compares four ways to structure a fixed or recurring deposit rate chart: one flat rate, slabs by term, slabs by amount, and combined term and amount slabs. Read each row for when the design fits and what it adds to maintenance. Confirm which slab dimensions your target Fineract release supports in its deposit configuration before settling on a design.
| Design | When it fits | Maintenance burden | Main risk |
|---|---|---|---|
| Single flat rate | One deposit product with a small, uniform customer base and a single pricing decision | Lowest: one rate to approve, load and review each time the market moves | Cannot reward longer terms or larger balances, so the product may not compete on price |
| Slabs by term only | Products sold on maturity length, such as 12, 24 and 36 month terms | Low to moderate: one rate per term band, reviewed at each rate change | Customers may split large deposits across accounts to chase a higher term band |
| Slabs by amount only | Products where larger balances warrant a higher rate and terms are fixed | Low to moderate: one rate per balance band, with boundary rules to confirm | Boundary wording (inclusive or exclusive limits) must match what the interest engine applies |
| Combined term and amount slabs | Products that price both length and size, typically with a larger customer base and a formal pricing committee | Highest: a grid of rates that must be entered, checked and reviewed as a set | Gaps or overlaps in the grid produce accounts with no rate or an unexpected rate |
| Recurring deposit variant | Regular savings plans where the monthly installment amount and term both matter | Moderate to high: term and installment bands interact, so test each combination | Installment changes or missed deposits may leave the applied rate out of step with the customer's plan |
Build, attach and verify a rate chart step by step
This sequence takes a rate schedule from finance approval to a fixed or recurring deposit product that applies the approved rates to new accounts. Each step ends with a check, so mismatches are found in a test tenant before any customer account is opened.
Agree the rate schedule with finance and product
Finance and product owners agree the schedule in writing before anyone configures Fineract. The schedule lists each deposit type, term band, amount band, rate, effective date and the day count and compounding basis that finance uses for the rate. The output is a signed schedule that the configuration will be checked against. Check that every band is written with explicit lower and upper boundaries and that no two bands share a value, so the schedule can be tested at each edge later.
Create the rate chart with its slabs
The implementation engineer creates the chart in Fineract's rate configuration, using the admin screens or the REST API for your release. Enter one slab for each band in the signed schedule, with term and amount ranges and the rate for each slab. Confirm the exact field names and endpoints in the platform documentation for your version before entering data. Check the saved chart by reading it back and comparing every slab row with the schedule, line by line, before moving on.
Set validity periods and review overlaps
Set the start and end dates of the chart so they match the effective dates in the schedule. If an earlier chart is still active for the same product, decide with finance whether it ends on the day before the new chart starts. Two active charts covering the same term and amount for the same product create ambiguity about which rate applies. Check that the validity dates give a single applicable chart for every date in the planned window, and record the decision in the change log.
Attach the chart to the deposit product
The product owner links the chart to the fixed deposit or recurring deposit product in the product configuration. Confirm that the product type is correct, since the same chart may be intended for one product only. Keep the product in a non-production tenant until testing is complete, and send requests with the Fineract-Platform-TenantId header for that tenant. Check the saved product by reading it back and confirming that the linked chart is the one approved in the previous steps.
Test rates at every slab boundary
Before opening accounts, the test lead calculates the expected rate for each boundary from the signed schedule. Use the lowest and highest amount in each band, the first and last term in each band, and values one step either side of each boundary. Include one date just before and one just after the validity window. The output is a table of test inputs and expected rates. Check that the expected rate for each row is taken from the schedule, not from the chart, so the test compares two independent sources.
Open test accounts and compare applied rates
The test lead opens fixed and recurring deposit accounts in the test tenant using the boundary inputs from the previous step. Record the rate the platform applies to each account and compare it with the expected value in the table. Repeat for each product type and for at least one account opened with a date at the edge of the validity window. Check that every row matches, and log any difference with the account identifier, the input values and the rate applied before the chart is changed.
Sign off and freeze the chart for production
Finance signs off the test table, and the change owner approves the move of the chart and product link to production through the usual change process. Once approved, restrict who can edit the chart, and record who approved it, the version of the schedule and the test evidence. Any later change to rates starts a new chart with its own validity dates and its own test cycle. Check that the production chart matches the signed schedule slab by slab before the first customer account is opened.
Managing chart validity periods without changing existing accounts
A validity period lets the bank publish a new rate schedule for future openings while leaving the rate already agreed on existing deposits untouched. The governance question is not whether Fineract can hold two charts, but who approves each chart, which effective dates it carries, and what the bank promises a customer who opened an account under the previous schedule. Treat every chart as a versioned business document with a named approver before it is entered in the system. Record the approval reference alongside the chart's start and end dates so an auditor can trace each rate back to a decision.
Overlapping charts are the main operational risk. Before go-live, define a rule that allows only one active chart per product, customer segment and deposit term at any moment, and test it with deliberately conflicting dates. Decide in advance what happens at a boundary date: whether a chart's end date is inclusive, which chart applies to an account opened on that day, and how a chart change scheduled in the middle of a business day is sequenced against the close of business. Write these rules down and test each boundary with a dated sample, because a one-day error at a boundary affects every account opened that day.
Confirm with the Fineract documentation and a test instance how the platform treats existing accounts when a chart changes or expires. Specifically ask whether the rate stored on an open deposit is fixed at opening, whether it is re-read from the chart at each interest run, and whether an expired chart can still be attached to a running account. Your answer determines whether a chart change is a product decision or a contract change for current customers, and it should be signed off by the risk and legal owners before any production chart is published.
Testing rate charts in sandbox, staging and production
The sandbox is where the product team builds and refines rate slabs. Work here is about getting the structure right: each term band and amount band is entered, overlaps and gaps are checked, and validity dates are set on a test chart. Nothing built here should be treated as a rate that customers will see, so the sandbox can be reset as often as the design requires. The product owner usually approves the design in this environment, with a second reviewer from the savings product team checking the slab logic against the signed product specification.
- Slab design: Enter each term and amount band as a separate row and confirm that no two slabs overlap for the same term.
- Boundary cases: Test amounts exactly on a slab edge, one unit below and one unit above, and a term at each boundary.
- Validity windows: Create charts with past, current and future validity dates and confirm which one is selected for a new account on a test date.
- Export of results: Save a dated record of the chart definition, the test cases run and the reviewer's name for each design version.
- Sign-off: Record the product owner's approval of the design before the chart is copied forward. Keep the sandbox evidence in the change ticket.
Before leaving the sandbox, confirm that the chart definition in the design record matches the rate schedule in the signed product specification, line by line.
Staging is where the chart is tested end to end against the data finance will reconcile. The copy of the chart should be loaded into a non-production environment that mirrors the production configuration, including the product it attaches to, the accounting mappings and the tenant. Finance supplies a set of reference accounts and expected outcomes, and the team opens new deposits against the chart and compares the applied rate, term and maturity amount with those expectations. Discrepancies go back to the design, not into a manual override.
- Reference scenarios: Agree with finance a set of new deposits covering each slab, each term and the chart's start and end dates, with expected rates and maturity values.
- Applied rate checks: Open test accounts and confirm the rate stored on each account matches the rate the chart gives for its term and amount at opening.
- Accounting alignment: Confirm that the interest accrual and maturity postings for the test accounts agree with the finance team's calculation.
- Access and roles: Confirm that only the named chart maintainers can edit charts and that the test results are kept in the change record.
- Sign-off: Finance and the product owner both approve the test results in writing before a production change is raised.
Ask the finance team to confirm which version of their reference calculation is the source of truth, because a mismatch often traces back to a different day-count or rounding assumption rather than a chart error.
Production publication should be a controlled, reviewed change, not a routine edit. The chart is applied to the product only after the staging evidence has been approved and the change has a defined effective date. The steps are planned so that the publication can be checked, and so that a failed publication can be stopped or reversed before customers open accounts against the wrong rates. Who approves depends on the organization's change policy, but the product owner, finance and the operations team typically each hold a separate approval.
- Change record: Link the approved staging evidence, the chart version, the effective date and the rollback plan in one change ticket.
- Timing: Schedule publication so that the validity start date is reached only after the change is verified, and confirm the time zone used by the system.
- Post-publication check: Open one controlled test account in production, or review the first few real openings, and confirm the applied rate against the chart.
- Rollback: Document how the product is returned to the previous chart and how accounts opened in the interim are reviewed.
- Retention: Keep the approvals, the chart export, the verification record and the timestamp of each change for the period your audit and record-keeping rules require.
Confirm with your auditors and your Fineract administrators which role may publish a chart, and whether that role can also approve its own change, because segregation of duties is often checked during assessments.
Where rate chart configurations usually go wrong
Most rate chart problems are not software defects. They come from how slabs, dates and product links were entered and never checked against the approved schedule. Each failure below has a check you can run before any new fixed or recurring deposit account is opened on the chart.
Overlapping rate slabs
When two slabs cover the same term or amount range, the rate applied to a new account depends on which slab the lookup matches first, not on the rate finance approved. Review every chart as a table of term and amount ranges and confirm that each combination of term and amount falls in exactly one slab. Test the boundary of each overlap by opening a test account at both ends of the range and recording the rate each one receives.
Gaps at boundary values
A slab that ends at 12 months and a next slab that starts at 13 months leaves any 12.5-month or fractional-period request without a rate. Likewise, an amount ceiling that stops at a round figure can leave deposits just above it unmatched. Confirm how Fineract treats values between slab ends and whether the upper bound of each slab is inclusive, then test a deposit at each gap. Do not assume the boundary behavior from another product.
Expired validity dates
A rate chart with a validity period that has ended, or one that has not started, can silently stop applying to new accounts. Staff may then open deposits on an old rate or find that the product has no valid chart on the opening date. Before each rate change, record the start and end dates on the chart, list the products that reference it, and confirm the chart in effect on the account opening date in a test run.
Charts attached to the wrong product
A chart linked to a savings or recurring deposit product that is not the one the front desk sells will apply the wrong rates to new accounts. This is easy to miss when several products share similar names or when a product is cloned for a campaign. Keep a written map of product codes to approved charts, and after any product change, open one account per product and compare its applied rate with the map.
Schedule mismatch with finance
The rate schedule approved by finance, often in a spreadsheet or policy memo, can differ from what was keyed into Fineract by a rounding step, a transposed slab or a missed tier. The error then flows into interest accrual and the ledger. Use a line-by-line comparison of the approved schedule against the chart export, with a named reviewer who signs off each difference before the chart is activated.
Questions teams ask before building deposit rate charts
What drives the effort of building a fixed deposit rate chart in Fineract?
The number of rate slabs, the number of terms and amount bands, and how many products share the same chart determine most of the effort. A chart with a few flat bands for one product is a short configuration exercise. A chart with many overlapping term and amount tiers, separate rates for each currency or branch, and several products that must reuse one chart takes longer to design, configure and check. Each extra slab adds data entry, a boundary test and a rate check against the approved schedule. Ask any provider to quote from a written list of slabs, products and validity periods rather than from a general description of the product.
Who should build the rate charts, our staff or a partner?
Your product owners should own the rates, and an engineer or partner should own how they are entered and tested. Product and treasury staff decide the rate table, the approval record and the effective dates, because those are business and policy decisions. A technical team familiar with Fineract's configuration and REST API is needed to create the charts, attach them to products and verify the rates applied to test accounts. If no one on staff has run a Fineract product configuration before, a fixed-scope partner engagement is usually the faster path, with your staff reviewing the result.
What must our team provide before a chart build can start?
You need an approved rate schedule, a list of products that will use it, and a clear rule for each term and amount band. The schedule should state the rate, the minimum and maximum amount, the term in periods, the currency and the date from which each version applies. You also need the expected behavior for rates that change while an account is open, and the names of the people who approve changes. A test set of sample accounts with known expected rates makes verification much faster. Missing rules discovered during testing are one of the most common reasons a build grows.
How long does a rate chart build take?
Duration depends on rate complexity, the number of products involved and how quickly your approvers confirm the schedule. A single chart with a short list of slabs can often be built and tested in a short cycle once the schedule is final. Multi-product setups, charts with many tiers, and integrations that read rates from another system take longer because each adds design and test work. Ask for the duration in the written scope, with the assumptions behind it, including the number of rate reviews you expect to run before go-live.
What changes the scope of a deposit rate chart project after it starts?
The most common scope changes are new slabs added after the schedule is signed off, new products that must share a chart, and rules that depend on a reporting or pricing system outside Fineract. Changes to the validity period logic, such as overlapping effective dates or retroactive rate updates, also add testing work. Each change should go through a written change request that states the added work and any effect on the timeline. Agreeing on a change control process before the build starts keeps these discussions short.
What should an engineer check after the rate chart is attached to a product?
Test a set of new accounts at each boundary of every term and amount band, including the minimum and maximum values and the first day of each validity period. Confirm that the rate applied to each account matches the approved schedule and that the chart rejects or flags amounts and terms that fall outside every band. Check that accounts opened before a rate change keep the rate their contract states, and that the rule is consistent across all products that share the chart. Record the test results so that finance and audit teams can see what was verified and when.
Does the rate chart need a separate security or compliance review?
Rate charts are configuration, but the rates they set affect customer payouts and regulatory disclosures, so they should go through your normal change approval and access control process. Restrict who can create or edit a chart, keep an audit record of each version, and confirm that the environment where tests run is separate from production. Your compliance team will decide which evidence they need. DeployOpen prepares systems and records for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
What a fixed-scope rate chart engagement covers
A rate chart build is scoped in writing before any configuration starts, and the scope fixes what is delivered: the rate chart definitions for the fixed and recurring deposit products in scope, the products each chart attaches to, the test cases used to prove the applied rates, and the handover pack. DeployOpen does not publish a price list, so the quote follows from that written scope. Ask for the scope to name each product, each chart and each validity window explicitly, so that a change request can be measured against a fixed baseline.
The client supplies the rate schedule as a signed, dated source document, not as an informal spreadsheet. For each chart, that document should list the term bands, the amount slabs within each band, the rate for every slab, the currency, the chart validity start and end dates, and any rule for rates that change mid-term. The team also needs the approved set of products, the branch or channel rules, and a named owner in finance who can confirm the expected result for each test account. Ambiguous slab boundaries, such as whether a deposit of exactly the threshold amount falls into the lower or upper band, are the most common cause of rework, so resolve them before the scope is signed.
Verification uses test accounts created in a non-production Fineract tenant, one for each product, term band and slab boundary in scope, with the expected rate recorded beside each account before the test runs. The handover documents the chart configuration as built, the test matrix and its results, the steps to attach or retire a chart, and the checks an operator runs when a new chart is loaded. Confirm with DeployOpen during scoping which support arrangement applies after handover, since ongoing support is offered as a separate retainer and is not implied by the fixed-scope delivery.
How DeployOpen delivers Fineract deposit configuration
DeployOpen plans, configures and documents fixed deposit rate charts in Apache Fineract inside infrastructure you control. The work starts from your written product rules and ends with verified rates on test accounts and a handover your team can run.
How we scope
- The written scope lists which deposit products use rate charts, the term and amount bands, and who approves each rate table.
- Scope names the Fineract environments involved, such as test and production tenants, and how changes move between them.
- Engagements are fixed-scope, so deliverables, acceptance tests and timelines are agreed in writing before configuration begins.
How we build
- We configure rate charts, slab boundaries and validity periods from your approved rate schedule rather than from memory of past products.
- We attach charts to fixed and recurring deposit products and test rates applied to new accounts across each term and amount band.
- We test edge cases such as boundary amounts, expired charts and accounts opened during a chart change, and record the results.
How we hand over
- You receive a written record of every chart, its validity dates, the products it is attached to and the test results behind it.
- Your operations team gets a runbook for creating, approving and retiring rate charts without changing the product definitions.
- Handover includes a review session where your finance and product staff confirm the applied rates match the approved schedule.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so rate changes can be checked after go-live.
- Support can cover re-verifying applied rates after a Fineract upgrade or a change to deposit product settings.
- Ask us to confirm in the quote which support tasks, response expectations and environments the retainer includes.
