Methodology — How It Works
Plain-language reference for every metric and formula in the platform. Written for business users.
Reading guide: Each metric below shows what it is, how it's calculated and why it matters. The formulas mirror what runs in src/utils/calculations.ts so finance and IT see the same picture.
Revenue Build-Up
How a single euro of client revenue is constructed before any cost is deducted.
Loan Spread Income
averageLoanBalance × (loanRate − ftpAssetRate)
What: The interest the bank earns on a client's loans, minus the internal cost of funding those loans.
Why it matters: Strips out interest-rate volatility so commercial pricing performance is visible separately from treasury.
Deposit Value Contribution
averageDepositBalance × (ftpLiabilityRate − depositRate)
What: The value the bank captures from a client's deposits — internal funding price minus the rate paid to the client.
Why it matters: Recognises that low-cost deposits fund higher-margin lending elsewhere in the bank.
NII after FTP
Loan Spread + Deposit Value Contribution
What: Total net interest income attributable to the client once internal transfer pricing has been applied.
Why it matters: The "true" interest contribution — comparable across clients regardless of balance-sheet structure.
Total Revenue (after FTP)
NII after FTP + annualFeeIncome + annualCardFeeIncome + fxFeeIncome
What: All revenue streams combined: net interest, banking fees, card fees and FX commissions.
Why it matters: Headline revenue figure used as the denominator for margin and ROR.
Gross Revenue (table view)
grossLoanInterest + Deposit Value + Fees + Card Fees + FX
What: Pre-FTP revenue shown in the Client Analysis table so users can see the gross figure and the FTP step explicitly.
Why it matters: Bridges naïve "revenue" understanding with the FTP-adjusted view used everywhere else.
FTP / Cost of Funds
averageLoanBalance × ftpAssetRate
What: Internal price the lending side pays to treasury for the funds it lends out.
Why it matters: Makes funding cost transparent and prevents loan-heavy clients from looking artificially profitable.
Cost Allocation
Three cost engines run in parallel: credit risk, activity-based operating cost, and payment scheme cost.
Cost of Risk
averageLoanBalance × expectedLossRate
What: Annualised expected credit loss on the client's lending exposure.
Why it matters: Forces high-risk relationships to absorb the cost of the risk they bring, not just the average book.
Operating Cost (ABC)
baseCost + transactionCost + rmCost + complexityCost
What: Activity-Based: €25K base + €3.5K per product, plus €1.20 per transaction, plus an RM-tier charge (€15K Low → €120K Premium), plus €8K per complexity-score point.
Why it matters: Replaces blunt cost averages with a build-up that reflects what each client actually consumes.
Card / Payment Cost
paymentVolume × 0.0018 + paymentVolume × 0.0008 + numberOfTransactions × €0.12
What: Visa/Mastercard scheme fees + processing cost + per-transaction fee — fully attributed to the client generating the activity.
Why it matters: Card cost is often hidden in central P&L; pulling it out exposes payment-intensive but unprofitable relationships.
Profitability KPIs
Net Profitability
Total Revenue − Cost of Risk − Operating Cost − Card Cost
What: The bottom-line profit the client contributes to the bank in a year.
Why it matters: The single number that decides whether a relationship is creating or destroying value.
ROR (Return on Revenue)
Net Profitability ÷ Total Revenue
What: How many cents of profit the bank keeps for every euro of revenue it earns from the client.
Why it matters: Comparable across clients of very different size — surfaces efficient relationships hidden behind small volumes.
Portfolio Margin (headline KPI)
Σ Net Profit ÷ Σ Revenue
What: Weighted portfolio margin — reconciles directly with the Total Revenue and Net Profitability cards on Executive Overview.
Why it matters: Avoids the trap of averaging per-client ROR (which would over-weight tiny clients and mislead the CFO).
Average Client ROR (secondary)
mean(ROR_i) across all clients
What: Simple arithmetic mean of individual ROR values. Available in code but NOT used as the headline KPI.
Why it matters: Documented for completeness so the difference vs. Portfolio Margin is explicit.
RORWA
Net Profitability ÷ RWA
What: Profit per unit of risk-weighted assets — connects profitability to capital consumption.
Why it matters: A relationship can be profitable on revenue but destroy value on capital. RORWA catches that.
Top 5 Profit Share
Σ profit(top 5) ÷ Σ profit(all positive contributors)
What: Concentration of bank profit in the five most profitable clients.
Why it matters: Quantifies concentration risk — a high number means losing one anchor relationship hurts disproportionately.
Profitability Class
Each client is bucketed into one of four classes based on margin (ROR). Used for colour-coding everywhere.
Highly Profitable
margin > 30%
What: Anchor relationships that generate disproportionate value.
Why it matters: Defend, deepen, never under-serve.
Profitable
10% < margin ≤ 30%
What: Solid contributors with healthy economics.
Why it matters: Standard service model is appropriate; look for cross-sell upside.
Marginal
0 < margin ≤ 10%
What: Above water but vulnerable to small shocks in cost or rates.
Why it matters: Candidates for repricing, fee deepening, or service-model simplification.
Value Destructive
margin ≤ 0
What: Relationships that consume more resources than they return.
Why it matters: Trigger management review — exit, restructure or radically reprice.
Visa / Mastercard Burden Insight
The Executive Overview flags clients where card costs materially distort profitability. A client must satisfy BOTH conditions to be flagged — preventing low-revenue clients with proportionally high card costs from triggering a false alarm.
Payment-Intensive Test
cardCost ÷ totalRevenue > 8%
What: Card cost consumes more than 8% of total revenue — the relationship is genuinely payment-driven.
Why it matters: Filters out clients who happen to have cards but where cards are a marginal part of their economics.
Burden Test
cardCost ÷ totalCost > 20%
What: Card cost makes up more than 20% of the client's total cost stack.
Why it matters: Quantifies the share of cost that comes from payment scheme & processing fees, not the bank's own service.
Implementation
getCardBurdenedClients(clients) — see src/utils/calculations.ts
What: Single source of truth — same function powers the insight card and any future drill-down.
Why it matters: No black-box logic. Threshold values are exported as constants and documented here.
Risk Inputs
Expected Loss Rate (input)
PD × LGD × (1 − recovery via collateral)
What: In this demo it is provided directly per client — in production it would be derived from PD × LGD with collateral haircuts.
Why it matters: Central credit-risk lever feeding both Cost of Risk and the action classification.
RWA
Bank-internal regulatory calculation (input)
What: Risk-Weighted Assets — capital consumed by the relationship.
Why it matters: Denominator of RORWA. Even a profitable client can underperform on a capital basis.
Scenario Analysis Levers
The Scenario Analysis tab applies six independent levers and re-runs the full calculation engine.
Margin Shift (bp)
loanRate ± Xbp
What: Simulates pricing power on the lending side.
Why it matters: Tests sensitivity of portfolio profit to commercial repricing.
EURIBOR-like Shift (bp)
ftpAssetRate ± Xbp ; ftpLiabilityRate ± Xbp
What: Moves both FTP curves in parallel — proxy for an interest-rate environment shift.
Why it matters: Surfaces clients whose value comes from cheap deposits (vulnerable when rates fall).
Fee Penetration (%)
annualFeeIncome × (1 + X%)
What: Tests upside from selling more fee-based products.
Why it matters: Quantifies the value of cross-sell campaigns.
Op Cost Reduction (%)
operatingCost × (1 − X%)
What: Models efficiency gains from process redesign or digitisation.
Why it matters: Shows where automation pays off most.
Card Cost Optimisation (%)
cardCost × (1 − X%)
What: Models renegotiated scheme fees or routing optimisation.
Why it matters: Highlights leverage on card-heavy clients.
Risk Cost Change (%)
expectedLossRate × (1 + X%)
What: Simulates a credit cycle deterioration or improvement.
Why it matters: Tests resilience of marginal clients to a downturn.
Demo disclaimer: All client data is fully synthetic. Formulas are illustrative — production deployment would tie FTP, RWA and EL inputs to the bank's official treasury, ALM and risk systems.