Source of Funds vs Source of Wealth in AML (and Crypto): how to ask the right question

In AML/KYC and EDD, Source of Funds (SoF) and Source of Wealth (SoW) often get treated as interchangeable. They’re not. And that confusion is one of the fastest ways to create blind spots in a review.

A lot of regulatory findings don’t come from missing controls — they come from teams answering the wrong question.

This post breaks down:

• what SoF and SOW really prove (especially in crypto),

• how they interact and how to turn both into a single, defensible narrative.
  

The simplest way to remember the difference

Source of Funds (SoF) = transaction-level question

“Where is this specific transfer originating from?”

SoF is about the last mile before the transfer. It explains the immediate source of the money used in a particular transaction.

Source of Wealth (SoW) = customer-level plausibility question

“How did the customer build their overall wealth over time?”

SoW is a plausibility test across time: does the customer’s story reasonably explain the level of wealth they appear to control?

If you mix these up, you can “prove” the wrong thing perfectly.

Why this distinction matters in practice

Think of SoF and SoW as two different types of validation:

• SoF proves the path (what funded this movement).

• SoW proves the story (why the customer can plausibly have this level of wealth and activity).

You can have:

• a clean SoF (traceable origin) and still a SoW that doesn’t add up (the customer profile can’t plausibly support it), or

• a credible SoW (wealth story makes sense) but a weak SoF (the funding route for a specific movement is unclear).

Strong reviews don’t pick one — they connect both.

Part 1: Source of Funds (SoF) — prove the last mile

What SoF is (and what it isn’t)

SoF is not “everything about the customer”. It’s not a life story. It’s not a full asset history.

SoF is the immediate origin of the funds used for a specific transfer.

Traditional examples:

• salary credits / business receipts / dividends

• sale of property or investments

• loan disbursements / refunds

• transfers from other accounts
  

SoF in crypto: common immediate origins

Crypto-linked SoF answers often look like:

• internal transfers from other accounts/wallets

• OTC trade proceeds

• mining / liquidity pool income

• ICO proceeds

• airdrops

• DeFi staking / lending / yield farming returns

• DeFi borrowing

• bounties / Web3 gig income
  

Two remarks that save real investigation time

1) Bridges/relayers/mixers are not the SoF question. Those can appear in many scenarios, but they don’t answer the core SoF prompt:where did this specific transfer originate from? Locking onto that question early can prevent hours of unnecessary blockchain work.

2) A SoF answer often hides another SoF (or even a SoW) question. Example: a customer says their SoF is “DeFi staking returns.”That may explain the last mile — but what funded the staking position in the first place?

• If it was funded by a single deposit → another SoF question.

• If it was built up over time (accumulated positions, long-term trading, repeated inflows) → this starts to become SoW.

SoF is frequently recursive: the first answer is often just the first layer.

Part 2: Source of Wealth (SoW) — plausibility over time

What SoW is (and what it isn’t)

SoW isn’t just “show me documents.” It’s a plausibility test.

Does the customer’s overall story reasonably explain the wealth they appear to control?

Typical SoW factors:

• career/business history

• long-term asset building

• inheritance, exits, investments

• lifestyle vs declared income

• whether the scale of activity and returns is plausible
  

SoW sets the context: what level of wealth and activity makes sense for this customer?

A practical nuance: intergenerational wealth

For very large amounts, the customer’s personal timeline may not be sufficient. Sometimes the review must consider intergenerational wealth:

• family businesses,

• inherited assets,

• trusts and structured wealth transfers.

This isn’t about being invasive — it’s about explaining reality when the numbers require it. The good news is that intergenerational wealth in crypto is almost non-existent.

SoW in crypto: same question, different shape

The SoW question in crypto is the same (“how did they build overall wealth?”), but there are a few twists that change how you evidence it.

1) Transfers + investments often happen in the same “account”

Crypto activity can behave like a current account and investment account combined: the same wallet/exchange balance is used for transfers, trading, and sometimes payments.

In traditional banking, these behaviours are often separated across products and accounts.

2) One story, distributed across many places

The customer story is typically spread across:

• many wallets (sometimes dozens),

• multiple centralised exchanges,

That distribution is often normal behaviour (diversification of counterparty risk, access to tokens/opportunities, operational convenience), but it makes compilation harder.

3) Returns are often the pressure point

Because the context has been historically more speculative (so far), the scale and plausibility of returns becomes central:

• “What investment strategy explains these outcomes?”

• “Are these returns plausible given the claimed timeline and exposures?”

• “Is the client a holder, day-trader, DeFi user, meme coin sniper, insider/protocol team member?”
  

4) Time-bounded narratives are common

Many crypto wealth stories cluster in a relatively bounded window (often post-2017):

• early positions taken and market appreciation (especially in BTC)

• increased activity in OTC and DeFi (especially after 2020).

This doesn’t make SoW trivial, but it often makes it stories structured.

5) A lot of relevant data is public

On-chain data can help validate parts of the story:

• timing patterns,

• wallet relationships,

• transaction history and flows.

Public data doesn’t replace customer evidence, but it can speed up or de-risk a narrative when used correctly.

Where teams get stuck: “clean SoF” but incoherent SoW

This is one of the most common failure modes:

The transaction is traceable. The documents look fine.But the customer story still doesn’t explain the scale.

Examples:

• repeated high-value inflows with no credible wealth-building narrative,

• “investment gains” claims that don’t match timing/exposure vs price action,

• wealth claims that would require earlier capital, which the story doesn’t explain.

This is exactly why SoW matters: traceability is not the same as plausibility.

On the other hand, a story does not need to be clarified to every penny. An 80-90% explanation is often good enough.

How to connect SoF and SoW into one defensible narrative

A practical approach that works across traditional finance and crypto-linked reviews:

Step 1: Separate the questions explicitly

• SoF: What funded this transfer (last mile)?

• SoW: What built this wealth level (over time)?

Write them at the top of your case notes. This simple act reduces drift.

Step 2: Build a timeline with two lanes

Create a timeline that distinguishes:

• 3rd party external inflows (transfers, income, financing, deposits),

• defi interactions (closed loop interaction with protocols)

• value creation / returns (investment gains, yields, realised outcomes).

In crypto reviews, this separation is often the difference between “messy story” and “defensible story.”

Step 3: Validate the “inputs” (SoF) before you explain the “outputs”

If the story relies on:

• staking returns, yields,  - you still need to validate the starting capital in the staking position

• Trading gains: you still need to validate the starting capital and the wealth-creation path for the activity (which assets, which platform, which period).
  

This is also a good example of the recursive SoF/SoW dynamic in action.

Step 4: Document why the story is credible (or why it isn’t)

A good write-up doesn’t just dump evidence. It explains reasoning:

• why the activity level is plausible for the profile,

• why the return narrative is plausible (or not),

• what assumptions were used,

• what gaps remain and how they impact risk.
  

A simple write-up template (copy/paste into your case notes)

1) Purpose This review assesses SoF for [transaction X] and SoW for the customer profile.

2) SoF conclusion The transfer originates from [immediate source], evidenced by [list items].Any upstream dependencies: [if SoF triggers another SoF/SoW question].

3) SoW narrative Customer wealth is explained by [career/business/inheritance/investments], supported by [items]. Activity/returns plausibility: [brief reasoning].

4) Consistency check SoF is/is not consistent with SoW and the customer profile because [reason].

5) Residual gaps and decision Open gaps: [list].Decision: [approve / escalate / decline] with rationale.

Common mistakes to avoid

Generic (fiat and crypto):

• Treating SoF as a full lifetime explanation (it isn’t).

• Treating SoW as “collect documents” rather than plausibility testing.

• Accepting “returns” as an explanation without validating starting capital and recalculating them using market data

• Writing notes that list evidence but don’t explain why the conclusion is defensible.
  

Crypto specific:

• Not analysing the whole story (missing/hidden wallets)

• Working with not-reconciled data

• Failing to separate 3rd party inflows and DeFi interactions from value creation

• Getting distracted by hops/bridges/technical mechanics instead of answering the SoF question together with the client

• Losing sight of the big picture
  

Closing thoughts 1. Answer the correct question

SoF and SoW belong to the same compliance conversation — but they answer different questions.

SoF gives confidence in the transfer. SoW gives confidence in the relationship (client credibility).

When you connect both, you don’t just “tick boxes” — you build a story that is clear, consistent, and defensible.

2. Working with crypto
   

Preparing SoW from crypto activity requires new knowledge and skills — and it’s often not feasible with traditional tools like Excel. Datasets can easily reach millions of rows and span multiple platforms, wallets, and exchanges.

If you’re looking to digitise crypto-related SoF and SoW end-to-end (from data collection and classification to structured narratives and audit-ready outputs), ChainComply is built for exactly that. Book a demo here: https://www.chaincomply.io/about-us#contact