Private bank portfolio fee tier testing verifies that a wealth platform applies the configured portfolio-fee rules to the correct assets, valuation date and client or household, then reports and posts the expected charge. Tests should cover tier thresholds, the bank's pricing method, eligibility rules and effective dates, with expected results calculated independently from the system under test.
Define the fee rules before testing
Start with an approved fee schedule and turn each rule into explicit inputs and expected outcomes. Confirm whether tiers use progressive marginal rates, where each rate applies only to assets within its band, or a single rate applied to the entire portfolio once a threshold is reached. These models produce different charges at the same portfolio value.
Document the fee basis as well. It may depend on eligible assets under management, account or household aggregation, currency conversion, valuation timing, billing frequency, minimums, caps, discounts or exclusions. Record how the schedule handles rounding, tax where applicable, and changes during a billing period. Treat each point as configurable only when the requirements say it is configurable.
Set preconditions for the test: a known fee schedule version, portfolio holdings and prices, a defined valuation date, client and household relationships, and any required foreign-exchange rates. Confirm that test data represents the intended state. A stale price, incorrect household link or wrong schedule effective date can make a correct calculation appear defective.
Test tier boundaries and calculation methods
Use boundary value analysis at every tier threshold. For a threshold of £1,000,000, test a feeable value just below it, exactly at it and just above it. Include the minimum fee or cap boundary if the schedule has one. Check that the selected rate and the resulting amount follow the documented rule, including the exact treatment of equality.
For a progressive schedule, test each band separately and a portfolio spanning several bands. For a whole-portfolio rate, test the rate change on the full eligible value at the threshold. A test that checks only one portfolio in the middle of a band can miss off-by-one comparisons and incorrect band selection.
Illustrative example: assume an annual progressive schedule charges 1.00% on the first £1,000,000 and 0.80% on the next £2,000,000. For eligible assets of £2,500,000, the expected annual fee before any other adjustments is £10,000 plus £12,000, or £22,000. This example assumes the schedule applies those rates to the stated bands and does not include proration, tax or rounding adjustments. Confirm the calculated amount against an independently implemented oracle or a reviewed hand calculation.
Cover data, dates and downstream results
Vary the inputs that can change the fee: eligible and excluded holdings, account currency, household membership, client mandate, schedule version and valuation date. Include zero or negative values where the system permits them, missing prices, unsupported currencies and incomplete account relationships. Negative or invalid inputs should produce the specified validation or exception outcome rather than silently entering a tier calculation.
Test effective-date behaviour around a fee schedule change and around the billing period boundary. If the approved rules require daily proration, verify the days attributed to each schedule and the calculation for each portion. Do not assume a particular proration convention; confirm it from the requirements. Re-run the same portfolio with an unchanged schedule to check that repeated processing does not create duplicate charges.
Follow the result through the relevant workflow. Compare the calculation detail with the client statement or fee notice, fee transaction and any accounting or reporting output in scope. Check that the displayed tier, fee basis, currency and amount agree. A correct calculation can still lead to a defect if a downstream posting uses a different amount or repeats the charge.
Make results reproducible
Store test fixtures with the schedule version, holdings, prices, exchange rates, client and household links, dates and expected results. Use synthetic or appropriately protected test data, and avoid dependencies on live market prices. Record calculation inputs and outputs so a failed assertion can be traced to the rule, source data or integration that caused it.
When results differ, inspect the fee basis and selected tier first, then check source valuations, eligibility mappings, dates, rounding and downstream postings. This separates calculation defects from data or integration failures. Automated tests can assert boundary values and API responses; a smaller set of end-to-end tests can verify that the fee reaches the client-facing and accounting outputs.
Frequently asked questions
How should a fee tier change during a billing period be tested?
Use a fixture with the old and new schedule effective dates, then verify the fee for each period segment using the bank's documented proration rule. Check the boundary date itself, the resulting total and the schedule version recorded for each segment.
Should private bank portfolio fee tests use production client data?
Use synthetic data where practical, or data that has been appropriately protected for the test purpose. Preserve the relationships and value ranges needed by the scenarios, and verify that sensitive client details cannot appear in test logs or evidence.
How can a tester tell a fee calculation defect from a valuation data defect?
Compare the calculation's recorded inputs with an independently verified fixture, including eligible holdings, prices, exchange rates and valuation date. If those inputs are wrong, investigate the data feed or mapping; if they are correct and the expected amount still differs, investigate the fee rules and calculation.