> ## Documentation Index
> Fetch the complete documentation index at: https://wiki.jamesvarga.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Five Lenses of Fintech

> A diagnostic framework for evaluating any fintech venture through five lenses — trust, risk, distribution, regulation, and harm — before building features.

The Five Lenses of Fintech is a strategic diagnostic that forces founders to evaluate their venture through trust, risk, distribution, regulation, and harm before investing in product features.

## What is this framework?

The Five Lenses framework was developed through the [Lessons from a Fintech](/projects/lessons-from-a-fintech) series. It addresses the most common failure mode in fintech: leading with features when the business is actually a trust business.

Every strategic decision in a fintech should pass through all five lenses. When a founder cannot answer questions across these lenses cleanly, the buyer fills in the blanks — and buyers fill blanks with risk.

## Who is it for?

Early-stage fintech founders, founding teams selling into banks or regulated institutions, and operators building products that handle money, data, or identity. It is also useful for investors evaluating fintech propositions and for enterprise buyers assessing vendor readiness.

## What are the five lenses?

```mermaid theme={null}
flowchart LR
  V[("Fintech venture")]
  V --> L1["Trust<br/>Who trusts whom?"]
  V --> L2["Risk<br/>What risk moves?"]
  V --> L3["Distribution<br/>How does it reach the user?"]
  V --> L4["Regulation<br/>What rules apply?"]
  V --> L5["Harm<br/>What happens when it fails?"]
```

| Lens             | Core question                                                       | What happens if you cannot answer                                         |
| ---------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| **Trust**        | Who is trusting whom with money, data, or identity?                 | You are a collection of features, not a financial business                |
| **Risk**         | What specific risk are you moving, shifting, or creating?           | Regulated buyers — who are paid to avoid risk first — will not engage     |
| **Distribution** | How does the product reach the user, and who owns the relationship? | You have hope, not distribution                                           |
| **Regulation**   | What rules shape what you can promise and how you handle data?      | You will be blocked at procurement or by the regulator                    |
| **Harm**         | What is the impact surface area when things go wrong?               | You design for the happy path and fail on the edge cases that matter most |

### Trust

A bank must trust you as a supplier. A consumer must trust you with their data. A carer must trust you not to harm their loved one. Without a clear trust model, your features are irrelevant.

### Risk

In regulated buying, people are paid to avoid risk first and grow second. You must prove you make the buyer safer, not just more innovative. If you cannot name the specific risk you reduce, you have not passed this lens.

### Distribution

This determines whether you own the customer or are a dependent in someone else's stack. B2C gives feedback speed but heavy support load. B2B2C offers leverage but involves "borrowed trust" — you inherit the partner's constraints and must operate entirely within their risk framework.

### Regulation

Not a legal afterthought — a product constraint from Day 1. In the UK, Consumer Duty mandates proven good outcomes for customers. Payment Scam Reimbursement rules create new liability. These are not hurdles; they are market readiness signals.

### Harm

In financial health, a mistake is not a bug — it can trigger missed rent, spiralling debt, or exclusion from essential services. This lens is especially critical when serving vulnerable populations: older adults, people under financial stress, or those with cognitive load constraints.

## How do you use it?

### The One-Sentence Definition exercise

If you cannot articulate your value in this format, you are still feature-first:

> "We help **\[who]** achieve **\[outcome]** by changing **\[trust or risk]** using **\[distribution]** while meeting **\[constraint]**."

Example: "We help older adults reduce missed payments by automating bill prioritisation through a partner bank app while meeting clear consent and complaints handling requirements."

### Non-negotiable product hygiene factors

Before any feature discussion, confirm five hygiene factors:

* **Clarity** — Can a user under cognitive load understand the next step?
* **Records** — Are audit trails robust enough to survive a regulatory inquiry?
* **Support** — Are there paths to resolution that do not rely on self-service?
* **Security** — Are access logs and data flow diagrams bank-ready today?
* **Proof** — Do you have measurable outcomes that prove the "better off" statement?

## What are the outputs?

* A clear trust model that names every trust relationship in the business
* A specific risk reduction statement for each buyer type
* A distribution strategy with named routes and owned relationships
* A regulation map showing how constraints shape the product
* A harm assessment covering edge cases and vulnerable users
* A one-sentence definition that passes all five lenses

## What are the common failure modes?

* **Leading with features instead of the trust model.** Answering "what does it do?" before "who trusts whom with what?"
* **Ignoring the buyer's silent questions.** The business sponsor asks about features. The risk committee silently asks about data breaches and vendor survival. See [the credibility gap](/knowledge/fintech-gtm/selling-to-banks).
* **"Partnerships" without a specific path.** If distribution is "partnerships" without a named route, you do not have distribution.
* **Regulation as afterthought.** Founders who treat regulation as a legal task discover too late that it is a product constraint.
* **Designing for the happy path only.** Not stress-testing edge cases for vulnerable users or high-harm scenarios.

## Related pages

* [Lessons from a Fintech](/projects/lessons-from-a-fintech) — the project that produced this framework
* [Fintech GTM](/knowledge/fintech-gtm/index) — commercial system for fintech products
* [How to sell fintech products to banks](/knowledge/fintech-gtm/selling-to-banks) — where the credibility gap plays out
* [Founder operating cadence](/knowledge/fintech-gtm/founder-operating-cadence) — the weekly rhythm for applying these lenses
* [Evidence packs for procurement](/knowledge/procurement/evidence-packs) — evidence that closes the trust gap
* [Consent and risk in open banking](/knowledge/open-banking/consent-and-risk) — consent as a trust mechanism
* [GTM Benchmark](/frameworks/gtm-benchmark) — commercial diagnostic showing whether the revenue motion is being limited by Volume, Efficiency, Control or Expansion
* [Making innovation 'free' in Fintech](/content/papers/making-innovation-free) — the staged deployment model for bank partnerships
* [Frameworks](/frameworks/index)

<script type="application/ld+json">
  {`
    {
    "@context": "https://schema.org",
    "@type": "HowTo",
    "name": "Five Lenses of Fintech",
    "description": "Strategic diagnostic that evaluates a fintech venture through five lenses — trust, risk, distribution, regulation, and harm — before investing in features.",
    "author": {"@type": "Person", "name": "James Varga", "url": "https://jamesvarga.com"},
    "step": [
      {"@type": "HowToStep", "position": 1, "name": "Trust lens", "text": "Identify who is trusting whom with money, data, or identity. Without a clear trust model, features are irrelevant."},
      {"@type": "HowToStep", "position": 2, "name": "Risk lens", "text": "Name the specific risk you reduce, shift, or create. Regulated buyers engage on risk reduction, not innovation."},
      {"@type": "HowToStep", "position": 3, "name": "Distribution lens", "text": "Map how the product reaches the user and who owns the relationship. Partnerships without named routes is hope."},
      {"@type": "HowToStep", "position": 4, "name": "Regulation lens", "text": "Identify the rules that shape what you can promise and how you handle data. Regulation is a product constraint, not a legal afterthought."},
      {"@type": "HowToStep", "position": 5, "name": "Harm lens", "text": "Assess the impact surface area when things go wrong, especially for vulnerable users. Stress-test the edge cases."}
    ]
    }
    `}
</script>