Face Value vs Book Value: The Credit Metric Every Fintech Engineer Needs to Understand
This is Part 3 in the fintech series. If you haven’t read the earlier entries:
- Part 1: How to Build an Accrual-Based Credit Ledger — the architecture behind events, postings, and reconciliations.
- Part 2: Build or Buy Your Fintech Ledger — when to build, when to buy, and how to design the transition.
This one is about a different problem entirely — one that surprises almost every engineer who joins a fintech for the first time.
The two numbers problem
You write a query to check a loan balance. The result shows two different values. Both are in active use. One appears on customer statements. The other appears on the balance sheet sent to the central bank. They don’t match. Nobody in the room can explain why in five minutes.
This is not a bug. It is a feature of financial accounting that every credit engineer needs to understand.
The two numbers are face value and book value. They answer different questions about the same loan. Confusing them is how fintechs produce financial statements that don’t reflect reality — and in some cases, how they collapse.
Part 1: Face value — what was promised
Face value is the original contractual amount the borrower agreed to repay. It includes the principal plus all future interest, fees, and charges as specified in the contract. It is deterministically calculable from the loan terms.
1
2
3
4
A borrower takes a R$10,000 personal loan at 3% monthly interest
over 12 months. The total contractual obligation is R$12,180.
Face value = R$12,180. Always. Even if they stop paying tomorrow.
Face value is immutable. It does not change when a borrower misses a payment, falls into delinquency, or defaults. It does not change when interest accrues or when fees are assessed — those movements are recorded separately in the ledger. Face value is the source of truth for what was promised.
An engineer thinks of face value as:
The immutable contractual record. Written once at origination. Never updated.
Part 2: Book value — what you will actually collect
Book value is what the company realistically expects to recover from the loan. It is face value minus the provision for expected credit losses (ECL).
1
2
3
4
5
Same R$12,180 loan. The borrower is now 90 days past due.
The credit risk model estimates a 40% probability of total default
with a 60% recovery rate. Expected loss = 40% × (1 - 60%) × R$12,180 = R$1,948.
Book value = R$12,180 - R$1,948 = R$10,232.
Book value is dynamic. It moves every time the credit risk assessment changes. A new payment brings it up. A missed payment brings it down. A macroeconomic shock that increases unemployment rates across the portfolio can cause thousands of book values to adjust simultaneously — even for loans whose borrowers haven’t missed a single payment.
An engineer thinks of book value as:
The financially honest view of the asset. Derived from face value minus expected losses. Always ≤ face value. Updated every assessment cycle.
The key insight is that both numbers are real. They answer different questions:
- Face value: “What did we agree this borrower would pay?”
- Book value: “What do we realistically expect to receive?”
Part 3: IFRS 9 — the standard that governs how book value moves
International Financial Reporting Standard 9 (IFRS 9) is the accounting standard that defines how credit losses must be provisioned. It replaced the older IAS 39 after the 2008 financial crisis revealed that waiting until a default was “probable” before recognizing losses was dangerously slow.
IFRS 9 introduced a three-stage model that recognizes losses earlier. Every loan starts in Stage 1 and migrates through Stages 2 and 3 as credit risk deteriorates.
The three-stage ECL model
| Stage | Trigger | Provision | Interest calculation |
|---|---|---|---|
| Stage 1 | No significant increase in credit risk | 12-month ECL (losses expected in next 12 months) | On gross carrying amount (face value) |
| Stage 2 | Significant increase in credit risk (e.g. 30+ days past due) | Lifetime ECL (losses expected over full remaining life) | On gross carrying amount (face value) |
| Stage 3 | Credit-impaired (e.g. 90+ days past due, default) | Lifetime ECL | On net carrying amount (book value) |
The engineering implication: the stage a loan is in determines the provision calculation and the interest accrual treatment.
Stage transitions are not cosmetic label changes. They are accounting events that change how revenue is recognized and how much capital the company must hold against the asset. A loan switching from Stage 1 to Stage 2 jumps from holding a 12-month provision to a lifetime provision — which can be 5–10x larger. This directly impacts book value and the company’s reported earnings.
What this means in practice
- Stage 1: Most performing loans. Provision covers only what’s expected to go wrong in the next 12 months. Book value is close to face value.
- Stage 2: The borrower is showing warning signs (30+ days overdue, forbearance, macroeconomic sensitivity). Provision covers the entire remaining lifetime of the loan. Book value drops sharply.
- Stage 3: The loan is impaired. The company no longer assumes full repayment. Interest now accrues on the book value (lower base), reducing reported income. Provision is still lifetime ECL. Book value is significantly below face value.
The exact triggers for stage transitions are set by each institution’s credit risk policy, but the standard provides a presumption that 30+ days past due triggers Stage 2 and 90+ days past due indicates default (Stage 3) — rebuttable with evidence.
Domain events for stage transitions
Stage transitions must be recorded as immutable domain events, not as updates to a status column. Each transition produces a ledger entry that credits the old provision balance and debits the new one. This is essential because:
- Auditors need to reconstruct the balance sheet as of any prior date.
- The P&L impact of a stage transition (provision expense) flows through the income statement.
- Reversals (a borrower cures and moves back to Stage 1) must be traceable.
In practice, a stage transition event looks like this in the system:
1
2
3
4
5
6
7
Domain event: STAGE_TRANSITION
loan_id: UUID
previous_stage: 2
new_stage: 3
trigger: "90 days past due"
provision_amount_delta: R$ 2,450 ← additional provision booked
effective_date: 2026-05-15
This event produces two ledger entries: one to reverse (part of) the old provision and one to book the new one. The total provision balance is always the sum of all provision entries in the ledger.
Part 4: The schema centrepiece
The separation between face value and book value is not just a conceptual distinction. It must be encoded in the database schema. Face value lives in an immutable record. Book value is always derived. They must never share a column.
Loan origination — face value lives here
1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE loan_contract (
loan_id UUID PRIMARY KEY,
borrower_id UUID NOT NULL,
principal_amount NUMERIC(18,2) NOT NULL, -- disbursed amount
contracted_total NUMERIC(18,2) NOT NULL, -- face value: principal + all future charges
currency CHAR(3) NOT NULL,
originated_at TIMESTAMPTZ NOT NULL,
maturity_date DATE NOT NULL,
status VARCHAR(20) NOT NULL, -- ACTIVE, DEFAULTED, SETTLED, WRITTEN_OFF
origination_data JSONB -- full contract terms for reference
);
contracted_total is the face value. It should be populated once at origination and never updated. If the contract is restructured, a new loan_contract row is created (with a restructured_from reference), and the original row becomes REFINANCED — but its contracted_total never changes.
Ledger entries — the append-only record of all movements
1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TABLE ledger_entry (
entry_id UUID PRIMARY KEY,
loan_id UUID NOT NULL REFERENCES loan_contract(loan_id),
entry_type VARCHAR(40) NOT NULL, -- DISBURSEMENT, ACCRUAL, PAYMENT, REVERSAL,
-- PROVISION_BOOKED, PROVISION_REVERSAL
debit_account VARCHAR(100) NOT NULL,
credit_account VARCHAR(100) NOT NULL,
amount NUMERIC(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
effective_date DATE NOT NULL,
created_at TIMESTAMPTZ NOT NULL,
idempotency_key VARCHAR(100) NOT NULL UNIQUE,
source_event_id UUID
);
The ledger records everything: disbursements, accruals, payments, reversals, and provision movements. Provision entries are just a special type of ledger entry. They credit the provision liability account and debit the provision expense account.
Credit provisions — the book value adjustment per assessment
1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE credit_provision (
provision_id UUID PRIMARY KEY,
loan_id UUID NOT NULL REFERENCES loan_contract(loan_id),
assessment_date DATE NOT NULL,
ecl_stage SMALLINT NOT NULL CHECK (ecl_stage IN (1, 2, 3)),
days_past_due INT NOT NULL,
provision_rate NUMERIC(5,4) NOT NULL, -- e.g. 0.2500 = 25%
provision_amount NUMERIC(18,2) NOT NULL, -- face value × provision_rate
gross_book_value NUMERIC(18,2) NOT NULL, -- face value at assessment
net_book_value NUMERIC(18,2) NOT NULL, -- gross_book_value - provision_amount
created_at TIMESTAMPTZ NOT NULL
);
Provisions are append-only. Each assessment creates a new row. Old rows are never updated or deleted. This preserves a complete audit trail of how the credit view evolved over time.
Deriving book value
Book value is never stored directly. It is always derived from the latest provision assessment:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
-- Current book value for a loan
SELECT
lc.loan_id,
lc.contracted_total AS face_value,
cp.gross_book_value,
cp.provision_amount,
cp.net_book_value AS book_value,
cp.ecl_stage,
cp.assessment_date
FROM loan_contract lc
JOIN credit_provision cp ON cp.loan_id = lc.loan_id
WHERE lc.loan_id = $1
ORDER BY cp.assessment_date DESC
LIMIT 1;
If you need the book value as of a specific date, you query the most recent provision row created on or before that date:
1
2
3
4
5
6
7
8
9
10
11
12
13
-- Book value as of a specific date
SELECT
lc.loan_id,
lc.contracted_total AS face_value,
cp.net_book_value AS book_value,
cp.ecl_stage,
cp.assessment_date
FROM loan_contract lc
JOIN credit_provision cp ON cp.loan_id = lc.loan_id
WHERE lc.loan_id = $1
AND cp.assessment_date <= $2
ORDER BY cp.assessment_date DESC
LIMIT 1;
This ability to query historical book values is not optional — regulators will ask for it.
Part 5: Common engineering mistakes
Confusing face value and book value in a ledger implementation produces failures that range from “reporting discrepancy” to “regulatory crisis.” Here are the most common mistakes I’ve seen.
Mistake 1: Using face value on the balance sheet
The balance sheet must report assets at their net realizable value — which is book value, not face value. Reporting face value overstates assets.
What happens: The company looks financially healthier than it is. Regulators flag the discrepancy during exams. Investors make decisions based on inflated asset numbers. In the worst case, a portfolio of non-performing loans appears valuable until the provision hole is discovered — the kind of surprise that kills fintechs.
This is not a hypothetical. Inadequate provisioning is a recurring theme in fintech failures. The accounting layer is not decoration — it is the ground truth.
Mistake 2: Updating face value when a payment is received
When a borrower makes a payment, the face value of the loan does not change. A payment reduces the outstanding balance, but the contractual total of what was promised remains what it was at origination.
What happens: If you update the face value on payment, you lose the contractual history. An auditor asks: “What was the original obligation for this loan?” The answer is “we don’t know — it changed every time the customer paid.” This is a failed audit before it begins.
The correct approach: record the payment as a ledger entry. Derive the outstanding balance by aggregating all entries. Never touch contracted_total.
Mistake 3: Storing book value in a mutable column
Some designs try to be clever: a book_value column on the loan_contract table that gets updated in place every time the provision changes.
What happens: You lose history. There is no way to reconstruct what the balance sheet looked like on December 31 of last year. When a regulator asks for that snapshot, you cannot provide it. In the US, the FDIC and OCC expect institutions to maintain a complete audit trail of allowance for credit losses (ACL). A mutable column cannot satisfy that requirement.
Book value must be derived, not stored. The provision table is append-only. The current book value is always the latest assessment. Historical book values are always available by date range.
Mistake 4: Accruing interest on book value for Stage 1 and 2 loans
IFRS 9 is explicit: interest on Stage 1 and Stage 2 loans accrues on the gross carrying amount (face value). Only Stage 3 (credit-impaired) loans accrue on the net carrying amount (book value).
What happens: If you accrue on book value for Stage 1 loans, you understate interest income. The P&L shows less revenue than accounting rules require. This cascades into understated tax liabilities, misstated earnings, and restated financial statements.
The implementation must check the current ECL stage before calculating accruals:
1
2
3
4
5
6
7
8
9
10
11
12
def calculate_interest(loan):
latest_provision = get_latest_provision(loan.id)
if latest_provision.ecl_stage == 3:
# Stage 3: accrue on book value
accrual_base = latest_provision.net_book_value
else:
# Stage 1 or 2: accrue on face value
accrual_base = loan.contracted_total
daily_rate = loan.interest_rate / 365
return accrual_base * daily_rate
Closing: write-offs and the road ahead
Eventually, a loan reaches a point where the company determines it will never recover anything more. At that point, the loan is written off: the face value is removed from the active portfolio, and the book value goes to zero.
Write-offs are a separate, complex topic with their own regulatory requirements, tax implications, and recovery workflows. They involve:
- Removing the asset from the balance sheet
- Reversing the remaining provision (which becomes a P&L gain)
- Moving the loan to an off-balance-sheet recovery process
- Continuing to track recoveries (if any) for years afterward
That article is coming next in this series.
For now, the fundamental rule is simple: face value is immutable. Book value is derived. Never confuse the two in your ledger implementation.
References
- IFRS 9 Impairment — Three-Stage Model — IFRS Community (the most practical explanation of ECL stages)
- IFRS 9 Financial Instruments — International Accounting Standards Board (official standard)
- BIS Summary: IFRS 9 Impairment — Bank for International Settlements (authoritative executive summary)
- Moody’s: IFRS 9 Challenges and the ECL Model — Moody’s Analytics
- PwC: IFRS 9 Provision Matrix Practical Guide — PwC (provisioning methodology)
- PwC: IFRS 9 vs US GAAP CECL Comparison — PwC Viewpoint
- Face Value — Corporate Finance Institute
- Book Value vs Fair Value — Corporate Finance Institute
- Disbursement Wallet: Face Value vs Book Value — Lendsqr Documentation (via Wayback Machine)
- Part 1: How to Build an Accrual-Based Credit Ledger — Paulo Gomes on dev.to
- Part 2: Build or Buy Your Fintech Ledger — Paulo Gomes on pvgomes.com