Data conflicts happen when two tools both think they “own” the same field. It is common in fintech stacks with a core ledger, a CRM, a risk engine, and a data warehouse. The fix starts with clear definitions and a field ownership map. This guide explains source of truth vs system of record in plain terms and gives a practical architecture pattern you can apply.

Source of truth vs system of record: the simple definitions

People mix these terms. They are related, but they are not the same.

What is a system of record (SoR)?

A system of record is the system that captures and stores data as part of a business process. It is where the “official entry” is written.

  • Example: The core ledger is the SoR for posted transactions.
  • Example: The card processor is the SoR for authorisations and settlements.
  • Example: The HR system is the SoR for employee job titles.

What is a source of truth (SoT)?

A source of truth is the place your company agrees to read from when it needs a final answer for a specific data element. It is the “decision” view.

  • It can be the same as the SoR.
  • It can also be a curated view that merges multiple SoRs.
  • It must be defined per field, not per system.

A system can be a system of record without being the source of truth for every field it stores.

Why data conflicts show up in financial infrastructure

Fintech teams often scale by adding specialist systems. Each one improves a workflow. But each one also creates new copies of data.

Conflicts usually come from a few repeat patterns.

  • Two write paths. Ops can edit the same field in two places.
  • Delayed sync. A batch job updates nightly. The UI needs real time.
  • Different definitions. “Customer status” means one thing in CRM and another in risk.
  • Derived fields stored as facts. A “current balance” snapshot gets written into many databases.
  • Weak contracts. APIs accept partial updates with no validation or version checks.

The practical pattern: field-level ownership with a single write path

The safest way to avoid conflict is simple: one system writes each field. Every other system reads it, caches it, or derives it.

Think in three layers.

  • Write owner (field SoR). The only place allowed to create or change the field.
  • Distribution. Events, CDC, or APIs that publish changes.
  • Read model (field SoT). The place users and services query for decisions, reporting, and joins.

Step 1: Define your “data domains”

Start with domains that match how your company works. In financial infrastructure, common domains include:

  • Customer and onboarding
  • KYC / AML and risk signals
  • Accounts and limits
  • Ledger and transactions
  • Cards and payments
  • Disputes and chargebacks
  • Pricing and fees

Step 2: Create a field ownership matrix

Do not assign ownership at the table level. Do it at the field level. That is where conflicts live.

Field Write owner (SoR) Source of truth for reads (SoT) Notes
Legal name Onboarding/KYC service Customer profile read model Lock after verification, track changes
Verified identity status KYC provider integration Risk decision service Derived from checks, not user-editable
Available balance Ledger Balance query service Compute from postings, avoid “manual” edits
Credit limit Credit policy service Limit service read model Versioned changes, approvals
Transaction status Payments processor Payments timeline view Handle reversals and late settlement

Step 3: Separate “facts” from “views”

In finance, facts are the audited record. Views are convenience.

  • Facts: postings, authorisations, customer submitted documents, risk decisions with timestamps.
  • Views: current balance, customer 360 profile, “active user” flags, dashboards.

Let the SoR store facts. Let the SoT serve the views. If you store views as facts, you will drift.

Choosing the right SoR and SoT for common fintech fields

Use these rules to decide quickly.

Rule 1: The SoR is where the business process happens

If the system is where the action happens, it is usually the SoR.

  • Ledger posts money movements.
  • CRM records support interactions.
  • Risk engine records decisions and signals.

Rule 2: The SoT is where the company answers questions

If multiple teams need one consistent answer, the SoT is often a curated model.

This is a common reason to build a dedicated read model for customer and risk data. It supports consistent monitoring and audit trails, which is a key part of system of record controls for financial crime.

Rule 3: Money data needs stricter ownership than profile data

For balances and postings, avoid shared writes.

For profile data, you may accept controlled edits. But still keep one write owner per field.

Architecture options that work in practice

You can implement the ownership pattern in a few proven ways. The best choice depends on latency, audit needs, and complexity.

Option A: Event-driven propagation (recommended for real time)

The SoR publishes domain events when a field changes. Other systems subscribe.

  • Pros: near real time, clear change history, less coupling.
  • Cons: needs idempotency, replay, and schema discipline.

This option gets safer when you also harden your APIs. Weak APIs are a top cause of duplicate writes. A good baseline is discussed in system of record API security.

Option B: Change data capture (CDC) for legacy SoRs

If you cannot change the SoR, CDC can stream database changes into a bus or warehouse.

  • Pros: minimal app changes.
  • Cons: hard to express business meaning, risky if schemas change.

Option C: Central “golden record” (use with care)

A master data system becomes the SoT for many fields. Teams push updates into it.

  • Pros: one place to query, good for deduping.
  • Cons: can become a bottleneck and invite shared writes.

If you use this, keep the write owner per field. Do not allow “anyone can update anything.”

Controls that prevent conflicts (even when people make mistakes)

Clear ownership is necessary. It is not enough. Add technical controls so the wrong writes fail fast.

Use strong contracts for updates

  • Validate inputs. Reject unknown fields.
  • Use optimistic locking. Add version numbers to avoid lost updates.
  • Make writes idempotent. Handle retries without duplicates.

Store lineage and timestamps

For each key field, store:

  • who changed it
  • when it changed
  • which system changed it
  • what the previous value was

This supports audit and helps you debug drift. It also maps well to the security concept of integrity in NIST’s definition of integrity.

Design for reconciliation

In finance, reconciliation is normal. Build it in.

  • Daily ledger-to-processor checks
  • Event counts and sequence checks
  • Exception queues with clear owners

A worked example: customer profile, KYC, and ledger

Here is a pattern that avoids the most common clashes.

Customer identity fields

Let the onboarding service be the SoR for submitted data. Lock fields when verified. Publish events on every change.

Build a customer profile read model as the SoT. It should merge:

  • submitted profile data
  • KYC verification results
  • risk flags and status

This is a good place to add scoring and decision context. It also matches the push toward fewer, higher quality systems described in a quality-over-quantity approach to your system landscape.

Balances and money movement

Let the ledger be the SoR for postings. Do not allow other systems to “fix” balances.

If you need fast reads, create a balance query service that builds a read model from ledger events. That service becomes the SoT for “current balance” reads.

For payment messages, common standards like ISO 20022 message definitions also benefit from clear field ownership. It reduces mismatched references and status codes across systems.

Anti-patterns to avoid

  • “The data warehouse is the SoR.” Warehouses are usually for analytics. They should not be your write system.
  • “CRM owns everything about the customer.” CRMs are great for interactions. They are often not right for identity verification facts.
  • Shared admin panels. If multiple teams can edit the same field in different tools, you will get drift.
  • Copying without contracts. Data “sync jobs” without schema and ownership rules create silent conflicts.

Quick checklist for deciding ownership

  • What is the business process? That system is a likely SoR.
  • Who needs the answer? That audience drives the SoT location.
  • Is the field a fact or a view? Facts belong in the SoR. Views can be in the SoT read model.
  • Is the field regulated or audited? Prefer append-only records and strong lineage.
  • Can more than one system write it? If yes, redesign until the answer is no.

FAQs

Can one system be both the system of record and the source of truth?

Yes. This happens when one system is the only writer and also the best place to read from. It is common for ledgers and payment processors.

Is a “single source of truth” always one database?

No. It is often a read model that is built from multiple systems of record. The key is that users and services know where to read the final answer for each field.

What if two systems must update the same field?

Try to remove that requirement. If you cannot, introduce a mediator service that becomes the single write path. It validates updates and writes to the true SoR.

Should the data warehouse be the source of truth for reporting?

Often, yes. For reporting and finance ops, a warehouse or lakehouse can be the SoT for curated metrics. But it should still be built from audited SoR facts, with clear transformation rules.

How do we roll this out without breaking production?

Start with one high-conflict area, like customer status or limits. Create the ownership matrix. Block writes in the non-owner systems. Then add events or CDC to keep consumers in sync.