AltVector – Value Ledger

Why a ledger exists

In a serious lending program, initiatives rarely arrive one at a time. A revised approval rule changes the pool. A pricing adjustment changes who accepts. A collections play changes loss timing. Governance guardrails prevent local overreach. The effects reinforce (and occasionally cancel) each other.

If every team reports impact in isolation, the sum can exceed the institution’s realised improvement. This is not a bad-faith mistake. It is a measurement mistake. The Value Ledger is designed to remove it.

Principle: start with what happened at the portfolio level, then allocate contributions in a way that can never exceed the truth.

What leaders get (and why it matters)

One verified value pool — a portfolio delta vs an agreed baseline, suitable for executive review.
Attribution that is bounded — contributions add up to the total, by construction.
Evidence links — cohorts, rollouts, decision logs, and guardrails attached to each ledger run.
A stable narrative — “what improved, where it showed up, and why it is attributable,” without quarterly re-litigation.

Related pages: ROI Lens • Partner Handoff • Credibility & Governance

How it works in practice

The ledger is deliberately procedural. It is not a “black box” and it does not require heroic data lifts. It is a sequence of checks that a CFO, CRO, or Head of Credit can follow.

Lock the baseline. Define the reference policy, comparison window, and what counts as value (loss reduction, income, recoveries, operational savings). This is where disputes are prevented.
Compute the verified value pool. Measure the portfolio delta vs baseline using agreed cohorts and outcome definitions. This is the only number allowed to be “the total uplift”.
Allocate by marginal contribution. Estimate how total value changes when each program is removed from the stack. This naturally captures interaction effects and prevents double counting.
Attach an audit trail. Every ledger run links to rollout configuration and guardrails. When questions arise, the answer is a pointer — not a debate.

A small example (illustrative)

Suppose the portfolio improves by 100 units vs baseline. Approvals and pricing both contributed — and they interacted: pricing worked partly because the pool changed. The ledger reports 100 units total, then splits it.

Approvals policy: 40 units
Pricing policy: 35 units
Collections play: 15 units
Guardrails: 10 units

The numbers above are illustrative. The point is the constraint: the total is bounded, and the split is explainable.

FAQs

What is the Value Ledger in one line?

A portfolio impact accounting layer: measure one verified value pool, then allocate contribution across programs with a marginal-contribution rule.

Why not just add up module ROI?

Because programs interact. Adding isolated ROIs can double count the same uplift. The ledger starts from the portfolio delta, so totals stay grounded.

Does this become a never-ending attribution argument?

Once baseline and the allocation rule are agreed, disputes typically reduce. People may debate strategy, but not arithmetic.

What data is needed at minimum?

Cohort outcomes, decision logs (what action was taken), and an agreed baseline definition. Identifiers can be minimised; the goal is defensible measurement.

How does this relate to experiments and rollouts?

Experiments provide clean comparisons; rollouts provide scale. The ledger records which cohorts were exposed and how value was computed, and links to the rollout configuration.

Last updated: 03 Jan 2026

Request a walkthrough