System of record for compliance evidence: what it is and why fintechs need one
Every regulated fintech eventually has to answer the question of what it knew about a customer on a specific date, and prove the record has not changed. The store that answers that question is a system of record for compliance evidence. Here is what makes something qualify, why the alternatives fall short, and where it sits in a fintech's stack.
The definition
A system of record for compliance evidence is the authoritative store of every signal, every decision, every override, and every policy version that touched a regulated customer. It is authoritative in the strict sense: every derived view (a data warehouse table, a BI dashboard, a case-tool cache) is downstream of it, and if it disappears the underlying facts become unprovable.
The term comes from enterprise architecture, where a system of record is the authoritative source for a business domain (the HR system of record for employee data, the ERP for financial transactions, the CRM for customer relationships). A compliance-evidence system of record extends the same idea to regulatory decisions: the store that holds the answer when an examiner, a sponsor bank, or a card network asks “what did you know on date X about customer Y, and prove it.”
The four properties any credible system of record must satisfy
Not every store of compliance data is a system of record. Four properties separate the two:
- Completeness. Every signal a vendor produced about the customer, every decision your team made on it, every override, every policy version that applied. Not a sample. Not the ones you remember. The examiner's question is about a specific customer on a specific date, and the answer has to hold every relevant event that touched the record on or before that date.
- Tamper-evidence. Any modification of a past record must be cryptographically detectable. Append-only is not enough (see how to keep a tamper-evident audit trail). The examiner has to be able to trust that what the system shows for a past date is what the system held then, not what it holds now.
- Continuity. The record survives a vendor swap, a system migration, or a business restructuring. When a KYC vendor changes or a case tool is replaced, the record stays continuous. Discontinuities in the chain are the most common audit failure and the reason so many teams struggle with sponsor-bank information requests that span a cutover.
- Provenance. Every signal is tagged with the vendor that produced it, the API version, the point-in-time context (what list version was current, what policy version applied). The examiner can distinguish between what your system currently knows and what it knew at the time the decision was made.
Any store missing any of the four is a partial log, not a system of record. Partial logs are often useful (a Splunk index, a data-warehouse table, a Datadog trail), but they cannot answer the examiner's question by themselves.
Why fintechs specifically need one
Traditional financial institutions have had systems of record for decades: the core banking platform is the system of record for balances, the general ledger for accounting, the loan origination system for credit decisions. Fintechs are newer, and typically start without a compliance-evidence system of record because the single-vendor-per-domain pattern makes it feel unnecessary.
That changes as the stack grows. A fintech at $100M annual processed volume typically runs one KYC vendor, one KYB vendor, one sanctions vendor, one transaction monitoring tool, and one fraud vendor. Six vendor consoles. When the sponsor bank asks about a specific customer, the compliance team assembles the answer by hand across all six. It takes days. At $500M volume, the same team runs 8-12 vendors and the assembly takes weeks. At $1B, information-request response time becomes the load-bearing constraint (see watching every fintech you sponsor from one record) that determines whether the sponsor bank keeps the relationship.
The moment a fintech has more than one vendor console per customer decision, it has an evidence problem. The moment a sponsor bank measures information-request response time, it has an evidence problem the bank sees. A system of record for compliance evidence is the structural fix.
What the alternatives cannot do
Four common structures get proposed as substitutes. None of them satisfy the four properties above.
- Data warehouse (Snowflake, Databricks, BigQuery). Holds derivative analytics data. Rebuildable from source systems. Not tamper-evident. Not designed to carry policy versions or override provenance. Excellent for reporting, not authoritative for compliance evidence.
- Case-management tool (Hummingbird, Unit21). Holds cases, not the underlying decisions that never became cases. The examiner's question about a customer usually covers the whole decision history, not just the escalated events. Case tools are complementary; not a substitute.
- Vendor logs (each KYC/KYB/fraud vendor's own audit trail).Per-vendor slices. None of them see the cross-vendor picture, and no vendor can produce an answer that includes decisions your team made on their signal. Also tied to the vendor relationship; when you swap vendors, the log becomes stranded.
- In-house evidence store (built on Postgres, Kafka, or S3).Common at scale. Achievable but expensive: getting all four properties right takes a serious engineering investment (typically two to four engineers for nine to twelve months, plus ongoing maintenance). Most fintechs discover this the year after the sponsor bank flags information-request response time.
Where a system of record sits in the stack
A system of record for compliance evidence sits beneath the vendor stack, not in it. The KYC vendor, the KYB vendor, the sanctions vendor, the fraud vendor, and the transaction monitoring tool all keep running. Their signals flow into the system of record alongside the rulebook that decides on them and the analyst overrides that adjust them. The vendor tools do not have to change; the system of record adds a layer beneath.
When a case tool escalates something (Hummingbird files a SAR, Unit21 disposes of a fraud alert), the disposition writes back to the system of record. When a sponsor bank asks about a customer, the answer comes from the system of record. When a federal examiner subpoenas history, the exam packet is produced by walking the record with a signed export.
The terminology map
The same architecture goes by several names depending on who is describing it:
- System of record. The enterprise-architecture term. Used when the buyer already thinks in terms of authoritative data stores. Common in bank procurement conversations.
- Single source of truth. Buyer-facing. Used on the FinQub homepage. Emphasizes that one query returns the answer rather than an assembly job across consoles.
- Compliance evidence layer. Product-category name. Sits below the vendor stack and above the persistence layer.
- Chain of provenance. Regulator and M&A term. Emphasizes the cryptographic and archival properties. Used when the audience is a compliance examiner or a diligence team.
All four describe the same thing from different vantage points. The properties (the four listed above) are the same regardless of the term used.
FinQub as the system of record
FinQub is the single source of truth for fintech risk decisions: the compliance-evidence system of record that sits beneath a fintech's vendor stack. Every KYC, KYB, sanctions, fraud, transaction monitoring, chain analytics, and card-network signal lands on one record per customer, with the decision the rulebook or the analyst made, the policy version pinned, and the analyst override if there was one. Tamper-evident by a per-Subject hash chain. Continuous across vendor swaps. Provenance-tagged on every event. Exam packets produced by walking the record with a signed export.
Frequently asked questions
What is a system of record for compliance evidence?
A system of record for compliance evidence is the authoritative store of every signal, decision, override, and policy version that touches a regulated customer. It is the source examiners, sponsor banks, card networks, and internal audit query when they need to know what a fintech knew and decided at a specific point in time. Every downstream copy (a data warehouse extract, a BI dashboard, a case tool cache) derives from it; the system of record itself is authoritative.
Is a system of record the same as a data warehouse?
No. A data warehouse holds derivative data optimized for analytics. It can be rebuilt from source systems. A system of record holds authoritative data and cannot be rebuilt: if the record is lost, the underlying decisions are unprovable. For compliance evidence, the properties that matter are integrity (tamper-evident), completeness (every event captured), continuity (chain unbroken across vendor swaps and system changes), and provenance (source tagged on every signal). Data warehouses satisfy none of those.
Do we need a system of record if our vendors already keep logs?
Vendors keep logs of what they emitted. Those logs are useful and often required, but they are per-vendor slices. The KYC vendor knows what its verification returned; the fraud vendor knows what score it produced; the sanctions vendor knows what its screening hit. None of them knows what your team decided on the whole picture, what policy version applied, or what override an analyst made. A system of record is what holds those together, and it is the store the examiner asks for.
How does a system of record differ from case management?
Case management (Hummingbird, Unit21) handles the investigation of an escalated alert: the workspace, the narrative, the filed SAR. A system of record holds the underlying evidence: every signal that led to the case, the decisions your team made, and every decision that never became a case. Case management is a layer on top; the record is the layer beneath. Both are needed; they solve different problems.
What are the four properties a credible system of record must satisfy?
Completeness (every signal and every decision is captured, not just a sample), tamper-evidence (any modification of a past record is cryptographically detectable), continuity (the record survives a vendor swap and produces one unbroken chain), and provenance (every signal is tagged with the vendor that produced it and the point-in-time context it arrived in). Any evidence store missing any of the four is not a system of record; it is a partial log.
A system of record for compliance evidence is a structural component, not a feature. See how a point-in-time replay uses it, or book a short walkthrough below.