Skip to content

Wirecard: The €1.9B That Existed and Didn't

The €1.9B both existed and didn’t — depending on which source you asked.

This is the financial forensics showcase. The same number, reported across four sources, took four contradictory positions over six years. YantrikDB stored every claim with source, validity, and polarity — and the contradiction cluster falls out of one query.

All sources are public record: Wirecard AG annual reports and BaFin filings, Ernst & Young audit opinions, Financial Times “House of Wirecard” investigative series (2015–2020), Bank of the Philippine Islands and BDO Unibank public statements (June 2020), Bangko Sentral ng Pilipinas circular (2020-06-21), Munich Public Prosecutor press releases.


SourcePositionAuthority
wirecard.filingThe €1.9B existsAnnual reports / BaFin filings
ey.auditThe €1.9B exists (unqualified opinion)External auditor
ft.investigationThe €1.9B does not existFT, from 2019-01-30
bpi.statement + bdo.statementThe accounts never existedThe named banks themselves
bsp.circularThe deposits never entered the Philippine banking systemPhilippine central bank

All five assert the same triple: (Philippine_trustee_accounts, balance_equals, EUR_1.9_billion). Two say YES. Three say NO. The validity windows span from 2014 (first reported) to 2020-06-25 (insolvency).


Phase 3: Eight polarity contradictions on one triple

Section titled “Phase 3: Eight polarity contradictions on one triple”
[1] Philippine_trustee_accounts --balance_equals--> EUR_1.9_billion
(wirecard.filing) CLAIMS EXISTS from 2018-12-31
(ft.investigation) CLAIMS DOES NOT from 2019-01-30
[2] Philippine_trustee_accounts --balance_equals--> EUR_1.9_billion
(wirecard.filing) CLAIMS EXISTS from 2014-01-01
(bpi.statement) CLAIMS DOES NOT from 2020-06-18
[3] Philippine_trustee_accounts --balance_equals--> EUR_1.9_billion
(ey.audit) CLAIMS EXISTS from 2014-01-01
(bsp.circular) CLAIMS DOES NOT from 2020-06-21
... and five more pairs

Every “yes” source paired against every “no” source — eight distinct polarity contradictions on a single (subject, relation, object) tuple. No vector DB, SQL table, or graph database can represent this without data loss.

Phase 4: The temporal query shows belief flipping

Section titled “Phase 4: The temporal query shows belief flipping”

On 2019-01-01 (before the FT broke the story):

[ey.audit] EXISTS (2014–2020-06-18, medium)
[wirecard.filing] EXISTS (2018-12-31–2020-06-18, high)
[wirecard.filing] EXISTS (2014–2020-06-18, high)

Belief state: everyone on record says the money is there.

On 2020-06-20 (day after the Philippine banks denied):

[bpi.statement] DOES NOT (2020-06-18–now, high)
[bdo.statement] DOES NOT (2020-06-19–now, high)
[ft.investigation] DOES NOT (2019-01-30–now, medium)

Belief state: three authoritative sources deny. Only Wirecard’s own filings remain in the claims table asserting existence — and they do remain, because YantrikDB never overwrites claims. They sit alongside the denials.

Same database. Same number. The answer to “what does the record say about the €1.9B?” genuinely depends on when you ask — because validity windows and source attribution are first-class data.


Why couldn’t Postgres + embeddings + a dashboard do this?

Section titled “Why couldn’t Postgres + embeddings + a dashboard do this?”

Any financial ledger built on SQL forces one value per cell. The moment BPI denies the account, a relational accounting system must either overwrite Wirecard’s claim (losing the fraud evidence) or bolt on timestamp columns and parallel “assertions” tables that only a forensic accountant would think to build. A vector database retrieves all four public statements as “similar” and makes no distinction between truth-claims and documented denials. A graph database can connect Wirecard to the accounts to the banks — but without polarity on the edges, it cannot represent “Wirecard claims this account exists” as a different kind of fact than “this account actually exists.”

YantrikDB stores the four contradictory positions on the same triple as four coexisting rows with opposite polarity, non-overlapping validity windows, and full source attribution. The contradiction cluster is the query result. That’s what the category is.


Every financial-forensics workflow where one number takes contradictory positions across sources:

  • Ponzi scheme unwinds — claimed returns vs actual flows vs whistleblower reports
  • Audit reconciliation — management representations vs external confirmations vs regulator findings
  • Sanctions compliance — company claims of non-exposure vs trade records vs enforcement actions
  • Transfer-pricing disputes — internal books vs tax authority findings vs partner company records
  • M&A due diligence — seller representations vs data room findings vs operational records
  • Whistleblower investigations — official filings vs internal communications vs external evidence

Every one of these becomes the same kind of structured contradiction reconstruction. The fraud is stored as a set of attributed claims whose polarities disagree across time.


Terminal window
git clone https://github.com/yantrikos/yantrikdb-server
python yantrikdb-server/docs/showcase/wirecard_engine.py \
ydb_your_token \
http://your-cluster:7438

Requires yantrikdb-server v0.7.2+ and yantrikdb v0.6.1+.

Full script: wirecard_engine.py


One number. Four sources. Four positions. Stored simultaneously, queryable at any point in time, surfaced as eight polarity contradictions automatically. That’s the category.