Section 07

Data governance & privacy

Who owns the data, how sensitive it is, where it may live, how long you keep it, whether you can trust it, and how teams share it safely. Section 06 covers how data is stored and moved. This section covers the rules around it. Encryption, hashing, tokenisation and key management are taught in 14 Security, and this page links to them.

7.1 Data governance basics Added

Data governance is the set of roles, policies and processes that decide who owns data, who may use it, and how it must be handled through its whole life.

๐Ÿ‘” Data owner

A senior business person who is accountable for a data domain (e.g. "Customer"). Approves access, and sets the classification and retention.

๐Ÿ“– Data steward

A business expert who looks after the data day to day: definitions, quality rules and glossary terms. Fixes quality issues.

๐Ÿ› ๏ธ Data custodian

Usually IT or the platform team. Stores, secures, backs up and moves the data, and applies the controls the owner asked for.

๐Ÿ‘ฉโ€๐Ÿ’ป Data consumer

Anyone who uses the data: analysts, apps, models. Uses it only for the approved purpose.

๐Ÿ›๏ธ Governance council / CDO

Sets the policies, settles disputes ("whose definition of 'active customer' wins?") and tracks maturity.

Building blockWhat it isExample
Policies & standardsThe written rulesClassification standard, retention schedule, access policy, data quality standard
Data catalogueA searchable inventory of datasets with owner, meaning, classification and lineageMicrosoft Purview, Collibra, Alation, Databricks Unity Catalog, DataHub (open source)
Business glossaryOne agreed meaning per business term"Active customer = at least one open account with a transaction in the last 12 months"
ProcessesHow rules are appliedAccess requests, data quality issue management, privacy impact assessments, periodic access reviews
  • The owner is the business, not IT. IT is the custodian.
  • Good governance makes data easier to use safely. If it only says "no", people go around it.
  • In Australian banking, APRA's CPG 235 Managing Data Risk describes the same owner / steward / custodian roles.
How to implement it
Library / APIPackageUse it for
Purview Data Map clientAzure.Analytics.Purview.DataMap previewRegister assets, glossary terms and lineage in Microsoft Purview from code. Still beta, so many teams call the Purview (Apache Atlas) REST API with HttpClient instead
Purview provisioningAzure.ResourceManager.PurviewCreate and configure the Purview account itself. Most teams do this in Bicep or Terraform

Governance is mostly process and platform. Don't build your own catalogue in .NET; feed an existing one.

"Who owns this data?" If the answer is "IT", you have a governance problem ๐Ÿšฉ

๐Ÿ‘” Owner: a business leader, accountable, approves access

๐Ÿ“– Steward: knows what the data means, keeps it clean

๐Ÿ› ๏ธ Custodian: IT/platform, stores and secures it as told

๐Ÿ”Ž Catalogue: so people can find data without asking on Teams

Governance done well is a fast lane for safe data use, not a speed bump. Who owns customer data in your organisation?

#DataGovernance #DataManagement #Architecture #Banking

7.2 Data classification Added

Classification labels data by how much harm its exposure would cause, so every dataset automatically gets the right controls.

๐ŸŸข Public

Safe to publish. Interest rates on the website, product brochures.

๐Ÿ”ต Internal

For staff only. Low harm if leaked. Org charts, internal procedures.

๐ŸŸ  Confidential

Harm to customers or the business if leaked. Customer names, contact details, balances, contracts.

๐Ÿ”ด Restricted

Serious harm. Card numbers, TFNs, passwords, health or hardship notes, bulk customer extracts.

Names vary (some use "Highly confidential" or "Secret"), but four levels like these are typical.

Personal information (PII)

Under the Privacy Act: information or an opinion about an identified or reasonably identifiable person. Name, email, address, phone, account number, and often device IDs or IP addresses when they can be linked to a person.

Sensitive information

A special Privacy Act category with a higher bar (usually needs consent): health, genetic and biometric data, racial or ethnic origin, religion, political opinions, sexual orientation, criminal record and more. Some data has its own rules too: card numbers (PCI DSS) and TFNs (the TFN Rule).

ControlPublicInternalConfidentialRestricted
EncryptionIn transitIn transit + at rest+ customer-managed keys+ field-level encryption or tokenisation
AccessAnyoneAll staffRole-based, need to knowNamed roles, approval, regular review, privileged access controls
MaskingNoNoIn non-prod and wide reportsAlways, except for approved roles
LoggingBasicBasicAccess loggedEvery read logged and alerted on
RetentionSet per data type by the retention schedule (see 7.5), not by level alone
Sharing outsideFreeWith approvalContract + privacy checkExceptional, encrypted, owner sign-off
  • A dataset takes the level of its most sensitive field.
  • Aggregation raises the level: one customer's postcode is low risk; a million names with postcodes and balances is not.
  • APRA CPS 234 requires regulated entities to classify information assets by criticality and sensitivity, and to match controls to that classification.
  • The cheapest control is not collecting the field at all.
How to implement it
Library / APIPackageUse it for
Data classificationMicrosoft.Extensions.Compliance.Abstractions (DataClassification, DataClassificationAttribute)Define your own taxonomy (Confidential, Restricted) and tag properties and parameters with it
RedactionMicrosoft.Extensions.Compliance.Redaction (AddRedaction, ErasingRedactor, HmacRedactor)Map each classification to a redactor: erase it, or replace it with a keyed hash
Log redactionMicrosoft.Extensions.Telemetry (EnableRedaction)Classified values in [LoggerMessage] logs are redacted before they reach any log sink
// Your taxonomy, matching the classification standard
public static class BankData
{
    public static string Name => "BankData";
    public static DataClassification Confidential => new(Name, nameof(Confidential));
    public static DataClassification Restricted => new(Name, nameof(Restricted));
}
public sealed class RestrictedAttribute() : DataClassificationAttribute(BankData.Restricted) { }

// Program.cs: redact classified values in logs
builder.Logging.EnableRedaction();
builder.Services.AddRedaction(r =>
{
    r.SetRedactor<ErasingRedactor>(BankData.Restricted);   // TFN, card number: removed
    r.SetHmacRedactor(builder.Configuration.GetSection("Hmac"),
                      BankData.Confidential);              // stable hash: still joinable
});

public static partial class Log
{
    [LoggerMessage(LogLevel.Information, "Loan application received for {Tfn}")]
    public static partial void LoanReceived(this ILogger logger, [Restricted] string tfn);
}

Not all data is equal. Classify it once, and the controls follow ๐Ÿท๏ธ

๐ŸŸข Public: rates on the website

๐Ÿ”ต Internal: staff procedures

๐ŸŸ  Confidential: customer contact details, balances

๐Ÿ”ด Restricted: card numbers, TFNs, health or hardship notes

The label drives encryption, access, masking, logging and sharing. Two traps: a dataset takes its most sensitive field's level, and combining "harmless" data can make it sensitive.

#DataClassification #Privacy #Security #DataGovernance

7.3 Privacy & PII handling Added

Privacy means collecting only what you need, using it only in ways people would expect, protecting it end to end, and respecting people's rights over it.

๐Ÿงฑ Privacy by design

Build privacy in from the first design, not as a fix later. Default to the most private setting.

โœ‚๏ธ Data minimisation

Collect and keep the smallest set of fields that does the job. Data you don't hold can't leak.

๐ŸŽฏ Purpose limitation

Use data for the purpose it was collected for, or a related one people would reasonably expect.

โœ… Consent & notice

Tell people what you collect and why. Get consent where the law requires it (e.g. sensitive information).

๐Ÿ™‹ Individual rights

People can ask to access and correct their data. Some laws add erasure and portability.

๐Ÿ”’ Security

Reasonable technical and organisational steps to protect it. See 14.5 and 14.7.

TechniqueReversible?Still personal info?Typical use
MaskingData is unchanged underneathYesCall-centre screens, receipts, reports
TokenisationYes, through the vault onlyYes, for whoever can reach the vaultCard numbers (shrinks PCI DSS scope), TFNs
PseudonymisationYes, with the key or mappingYesAnalytics and ML where you need to join records per person
AnonymisationNoNo, if done properlyOpen data, research, aggregate dashboards
Law / schemeWhat architects need to know
Privacy Act 1988 and the 13 Australian Privacy Principles (APPs)Applies to government agencies and most organisations with turnover over $3M (and always to some, such as AML/CTF reporting entities and health providers). Key APPs: APP 1 open privacy policy, APP 3 collection, APP 6 use and disclosure, APP 8 overseas disclosure (see 7.4), APP 11 security, plus destroy or de-identify data you no longer need, APP 12/13 access and correction.
Notifiable Data Breaches (NDB) schemeSince February 2018. If a breach is likely to cause serious harm, notify the OAIC and affected people as soon as practicable. Assess a suspected breach within 30 days.
2024 amendments (Privacy and Other Legislation Amendment Act 2024)Tranche 1 of the reforms, passed December 2024: tiered civil penalties and new OAIC infringement and compliance notice powers; "reasonable steps" now explicitly includes technical and organisational measures; a statutory tort for serious invasions of privacy (from 10 June 2025); a Children's Online Privacy Code; and from 10 December 2026 privacy policies must explain automated decisions that significantly affect people.
Tranche 2 (proposed)An exposure draft (Privacy Amendment (Personal Data Protection) Bill 2026) was released in August 2026: a "fair and reasonable" test, stronger consent, and a right to erasure for large digital platforms. It is not law yet.
GDPR (EU), in briefCan apply to Australian firms that offer services to, or monitor, people in the EU. Needs a lawful basis for each use; breach notification to the regulator within 72 hours; rights to access, erasure and portability; fines up to โ‚ฌ20M or 4% of global turnover. Pseudonymised data is still personal data.

Australia has no general "right to be forgotten" today. But APP 11.2 already requires you to destroy or de-identify personal information you no longer need, so you need deletion pipelines anyway (see 7.5).

  • Pseudonymised โ‰  anonymised. If anyone can re-link it, privacy law still applies.
  • Run a privacy impact assessment (PIA) early for any new use of personal data, especially AI and analytics.
  • Keep legal calls with privacy and legal teams. The architect's job is to make minimisation, masking, access and deletion easy to do.
How to implement it
NeedLibrary / APINotes
Protect a field in the appbuilt-in ASP.NET Core Data Protection (IDataProtectionProvider, IDataProtector)Encrypt values with keys the framework manages and rotates. A purpose string keeps each use separate
Shared key ringAzure.Extensions.AspNetCore.DataProtection.Blobs + Azure.Extensions.AspNetCore.DataProtection.KeysStore the key ring in Blob Storage and wrap it with Key Vault, so every instance can decrypt
Encrypt columns in SQLMicrosoft.Data.SqlClient Always Encrypted (Column Encryption Setting=Enabled) + Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProviderThe driver encrypts and decrypts on the client, so the database and DBAs never see plain TFNs
Mask on readSQL Server / Azure SQL Dynamic Data MaskingSet in T-SQL (MASKED WITH (FUNCTION = 'partial(...)')). No app change, but it is display-only, not security
PseudonymiseHmacRedactor (Microsoft.Extensions.Compliance.Redaction); built-in HMACSHA256Same input + same key = same ID, so analysts can join records without seeing who it is
public sealed class TfnProtector(IDataProtectionProvider provider)
{
    // The purpose string isolates this use: a protector for "Marketing" can't read these
    private readonly IDataProtector _protector = provider.CreateProtector("Customer.Tfn.v1");

    public string Protect(string tfn) => _protector.Protect(tfn);
    public string Unprotect(string stored) => _protector.Unprotect(stored);
}

// Program.cs: persist and protect the key ring so data survives restarts and scale-out
builder.Services.AddDataProtection()
    .PersistKeysToAzureBlobStorage(blobUri, new DefaultAzureCredential())
    .ProtectKeysWithAzureKeyVault(keyUri, new DefaultAzureCredential());

If you lose the Data Protection key ring, anything you stored with it can never be decrypted. Persist it, back it up, and never delete old keys while data still uses them.

Masked, tokenised, pseudonymised, anonymised. They are NOT the same thing ๐Ÿ•ต๏ธ

๐ŸŽญ Masked: "โ€ขโ€ขโ€ขโ€ข 1234" on screen. The real value is still stored.

๐Ÿ” Tokenised: a random token; only the vault can swap it back.

๐Ÿ”‘ Pseudonymised: a keyed ID. Re-linkable, so still personal information.

๐ŸŒซ๏ธ Anonymised: can't be linked back to anyone. Prove it before you claim it.

And in Australia: from 10 December 2026, privacy policies must explain automated decisions that significantly affect people. Does yours?

#Privacy #PrivacyByDesign #DataProtection #Australia

7.4 Data residency & sovereignty Added

Residency is where data physically sits. Sovereignty is whose laws can reach it. Localisation is a rule that says it must stay in a country.

๐Ÿ“ Residency

"Our data is stored in Australia East and Australia Southeast." A fact about location, usually chosen for regulation, contracts or latency.

โš–๏ธ Sovereignty

Which governments can compel access. A foreign-owned provider may be subject to its home country's laws even for data stored in Australia.

๐Ÿšง Localisation

A legal or contract rule that data must not leave a country. Some government and defence work has this.

Architecture optionHowWatch out for
In-country regions onlyDeploy to Australia East + Australia Southeast (a paired region set), or Australia Central for government workSome services aren't in every region; global services may process metadata elsewhere
No replication outside the regionChoose geo-redundant storage with an in-country pair, restrict database replicas to AU regionsBackups, logs, CDN caches and AI endpoints are easy to forget
Keys held in-countryCustomer-managed keys in an AU Key Vault or Managed HSM. You can revoke access by disabling the keyIf you lose the key, you lose the data
Policy guardrailsAzure Policy "allowed locations", AWS SCPs or GCP organisation policies that deny other regionsApply at the management-group or organisation level so new projects inherit them
Regional cells (multi-country firms)A separate deployment ("cell") per country, with only aggregated or anonymised data shared centrallyCost and duplicated operations; global reporting is harder
  • Residency โ‰  sovereignty: data stored in Sydney can still be reachable by a foreign government through the provider.
  • Map every copy: primary, replicas, backups, logs, analytics, AI prompts and support access.
  • Enforce location with platform policy, not just app settings.
How to implement it
NeedLibrary / APINotes
Region-aware database clientMicrosoft.Azure.Cosmos: CosmosClientOptions.ApplicationRegion / ApplicationPreferredRegionsRead and write from the nearest of the regions the account replicates to
In-region resourcesAzure SDK clients (BlobServiceClient, SecretClient, โ€ฆ) pointed at in-region endpointsThe resource's location is fixed when it is created. The client just calls that endpoint
In-country keysAzure.Security.KeyVault.Keys against an AU Key Vault or Managed HSMCustomer-managed keys for storage and databases stay under your control in Australia
GuardrailsAzure Policy "Allowed locations" (Bicep / Terraform)Platform configuration, not app code
var cosmos = new CosmosClient(accountEndpoint, new DefaultAzureCredential(), new CosmosClientOptions
{
    // The account itself only replicates to these two AU regions
    ApplicationPreferredRegions = [Regions.AustraliaEast, Regions.AustraliaSoutheast]
});

The client option only picks between regions the account already has. Residency is decided by which regions you add to the account, and enforced by policy.

"Our data is in Australia, so we're fine." Are you sure? ๐ŸŒ

๐Ÿ“ Residency: where the bytes sit

โš–๏ธ Sovereignty: whose laws can reach them

๐Ÿšง Localisation: a rule that they must never leave

๐Ÿ” The usual leaks: backups, logs, CDN caches, AI endpoints, and offshore support staff reading production data

Map every copy, keep the keys in-country, and enforce allowed regions with policy, not good intentions.

#DataSovereignty #CloudArchitecture #Privacy #Azure

7.5 Data retention & deletion Added

Keep data as long as the law and the business need it, and no longer. Then delete it everywhere, including the copies.

Data (Australian examples)Keep forDriver
AML/CTF transaction records7 years from when the record is madeAML/CTF Act (AUSTRAC)
AML/CTF customer due diligence (KYC) records7 years after the customer relationship endsAML/CTF Act (AUSTRAC)
Company financial records7 years after the transactionsCorporations Act
Personal information you no longer needDestroy or de-identifyPrivacy Act, APP 11.2
App and security logsYour policy (e.g. 90 days hot, 1 year archive)Security monitoring and investigations

A retention schedule lists every data type, how long to keep it, why, and what happens at the end. When several rules apply to the same record, keep it for the longest period that applies, and no longer.

Storage lifecycle policy: move data to cheaper tiers as it cools, then delete it
Hotdays to months ยท frequent reads
โ†’
Cool / coldrare reads ยท cheaper
โ†’
Archivehours to restore ยท cheapest
โ†’
Deleteend of retention

โš–๏ธ Legal hold

Litigation, a regulator or an investigation can freeze deletion for specific records. A hold overrides the schedule until it is released.

๐Ÿ—‚๏ธ Soft vs hard delete

Soft delete (an IsDeleted flag) is handy for undo. It is not deletion for privacy or retention. Plan the hard delete too.

๐Ÿ’พ Backups

You usually can't edit backups. Let them age out on a short, documented cycle, and keep a deletion log that is replayed after any restore.

๐Ÿ“œ Logs

Keep personal information out of logs in the first place (see 7.2 redaction). Then log retention is easy.

๐Ÿ”‘ Crypto-shredding

Encrypt each customer's (or each period's) data with its own key. Delete the key, and every copy, including backups, becomes unreadable. Key management: 14.7.

  • Over-retention is a risk, not a safety net: old data is breach exposure with no business value.
  • Deletion must reach every copy: replicas, history tables, lake files, extracts, caches, backups and search indexes.
  • AML/CTF records are generally kept for 7 years; check the exact trigger (record made vs relationship ended).
How to implement it
NeedLibrary / APINotes
Soft deleteMicrosoft.EntityFrameworkCore: HasQueryFilterHide deleted rows from every query automatically. EF Core 10 adds named filters you can switch off one at a time
HistoryMicrosoft.EntityFrameworkCore.SqlServer: IsTemporal(), TemporalAsOfSQL Server temporal tables keep every old version for audit and point-in-time reads
Legal hold / WORMAzure.Storage.Blobs: SetLegalHoldAsync, SetImmutabilityPolicyAsyncMake blobs undeletable until the hold is cleared or the policy expires
Tiering & expiryBlob lifecycle management policy (Bicep, or Azure.ResourceManager.Storage)Rules like "cool after 30 days, archive after 1 year, delete after 7 years". Platform config, not app code
Crypto-shreddingAzure.Security.KeyVault.Keys: KeyClient.StartDeleteKeyAsync, PurgeDeletedKeyAsyncOne key per customer or per period. Delete and purge the key to make the data unreadable
protected override void OnModelCreating(ModelBuilder b)
{
    b.Entity<Customer>(e =>
    {
        e.HasQueryFilter(c => !c.IsDeleted);          // soft delete: hidden from normal queries
        e.ToTable("Customers", t => t.IsTemporal());  // SQL Server keeps every old version
    });
}

// Audit question: "what did we hold for this customer on 31 January?"
var asAt = await db.Customers
    .TemporalAsOf(new DateTime(2026, 1, 31, 0, 0, 0, DateTimeKind.Utc))
    .SingleAsync(c => c.Id == customerId);

Temporal history tables and Key Vault soft-delete both keep data on purpose. Your erasure process must purge history rows too, and purge protection on a vault means a deleted key can't be purged until its retention period ends.

Deleting a customer's data is harder than storing it ๐Ÿ—‘๏ธ

๐Ÿ“‹ Start with a retention schedule: what, how long, why

โš–๏ธ Legal hold beats the schedule until it's released

๐Ÿ’พ Backups: short cycles + a deletion log replayed after restore

๐Ÿ”‘ Crypto-shredding: one key per customer; delete the key and every copy is unreadable

Old data you don't need isn't an asset. It's breach exposure. When did you last delete anything on purpose?

#DataRetention #Privacy #DataGovernance #CloudArchitecture

7.6 Data quality & lineage Added

Data quality measures whether data is fit for its purpose. Lineage shows where data came from, how it changed, and where it goes.

๐ŸŽฏ Accuracy

Matches reality. The address on file is where the customer actually lives.

๐Ÿงฉ Completeness

Required values are present. No customers without a date of birth.

๐Ÿ”— Consistency

Agrees across systems. The balance in the ledger equals the balance in the data warehouse.

โฑ๏ธ Timeliness

Fresh enough for its use. The fraud feed lands within 5 minutes.

โœ… Validity

Follows format and rules. A BSB has 6 digits; amounts are positive.

1๏ธโƒฃ Uniqueness

No duplicates. One record per customer (see 7.7).

Quality gates in a pipeline: check early, quarantine bad rows, never fail silently
Source feed
โ†’
Schema checkcontract (7.8)
โ†’
Rule checksnull, range, format, reconcile
โ†’
Curatedpassed rows
Quarantinefailed rows + alert the steward
Lineage: trace a number on a report back to its source
Core banking
โ†’
CDC6.8
โ†’
Lake: raw
โ†’
Lake: curatedjoins, rules
โ†’
Risk report"total exposure"
  • Fix quality at the source and as close to capture as possible. Cleaning downstream forever is the expensive option.
  • Measure quality as numbers with thresholds and owners, not as opinions.
  • Quarantine and alert. Don't silently drop bad rows or load them anyway.
How to implement it
NeedLibrary / APINotes
Validate at the API edgebuilt-in ASP.NET Core 10 minimal API validation (builder.Services.AddValidation() + DataAnnotations)Rejects bad input before it is stored, which is the cheapest place to fix quality
Rich rule setsFluentValidationReusable rules for APIs, files and pipeline rows: completeness, validity and cross-field checks
Lineage & catalogueAzure.Analytics.Purview.DataMap previewPush custom lineage into Purview from a .NET job
OpenLineage eventsbuilt-in HttpClient + System.Text.JsonThe official OpenLineage clients are Java and Python. From .NET, POST the JSON run event to the lineage endpoint (e.g. Marquez)
public sealed class CustomerRowValidator : AbstractValidator<CustomerRow>
{
    public CustomerRowValidator()
    {
        RuleFor(r => r.CustomerId).NotEmpty();                      // completeness
        RuleFor(r => r.DateOfBirth).NotNull();                      // completeness
        RuleFor(r => r.Postcode).Matches(@"^\d{4}$");               // validity (AU postcode)
        RuleFor(r => r.Balance).GreaterThanOrEqualTo(-1_000_000m);  // sanity range
    }
}

foreach (var row in rows)
{
    var result = validator.Validate(row);
    if (result.IsValid) curated.Add(row);
    else quarantine.Add(new QuarantinedRow(row, result.Errors));  // alert the steward
}

"The numbers in the report are wrong." The 3 questions that decide how bad your week is ๐Ÿ“‰

1๏ธโƒฃ Which quality check should have caught it? (accuracy, completeness, consistency, timeliness, validity, uniqueness)

2๏ธโƒฃ Where did the bad data come from? That's lineage.

3๏ธโƒฃ What else uses it? That's lineage too.

๐Ÿšง Quality gates + quarantine in every pipeline. Never fail silently.

Trustworthy data is a design choice, not luck.

#DataQuality #DataLineage #DataEngineering #DataGovernance

7.7 Master data management (MDM) Added

MDM creates one trusted golden record for core business entities, such as customer and product, that many systems share.

๐Ÿ‘ค Master data

The core "nouns" of the business, shared by many systems: customer, product, account, supplier, employee.

๐Ÿ“š Reference data

Standard code lists: country codes, currencies (ISO 4217), BSB directory, merchant category codes. Small, slow-changing, often external.

๐Ÿ’ณ Transactional data

Events that involve master data: payments, orders. High volume. Not what MDM manages.

MDM styleHow it worksGood forTrade-off
RegistrySources keep their data. The hub holds only match links and IDs, and builds the view on demandFast start, no change to source systemsSources stay messy; the view is read-only
ConsolidationCopy data into the hub, match and merge into golden records for analyticsReporting and a single customer viewGolden record doesn't flow back to sources
CoexistenceLike consolidation, but the golden record is synced back to sourcesGradual move to clean data everywhereTwo-way sync and conflict rules are complex
Centralised (transaction)The hub is the system of record. New data is created and changed only thereHighest quality and controlMost invasive and costly; every app must change
  • MDM is mostly process and stewardship, then tooling. Agree who owns each field first.
  • Tune match thresholds with stewards: false merges (two people merged into one) are worse than missed matches in banking.
  • Start with registry or consolidation; go centralised only when the business case is clear.
How to implement it
NeedLibrary / APINotes
Fuzzy name matchingFuzzySharpOpen-source port of Python's fuzzywuzzy: ratio and token-sort scores for "Jane Citzen" vs "Jane Citizen"
Phonetic matching in SQLSQL Server SOUNDEX / DIFFERENCECheap blocking step to find candidate pairs before detailed scoring

There's no standard .NET MDM library. Real MDM uses a dedicated platform; .NET code usually integrates with it through APIs or events.

Your bank has 3 versions of you. MDM picks the truth ๐Ÿ‘ค

๐Ÿ—‚๏ธ CRM: right email

๐Ÿฆ Core banking: verified date of birth

๐Ÿ’ณ Cards: newest address (and a typo in your name)

๐Ÿ”— Matching finds they're the same person. โš–๏ธ Survivorship picks the best value per field. โญ Result: one golden record.

Rule of thumb: a false merge (two people become one) is worse than a missed match.

#MDM #MasterData #DataQuality #Banking

7.8 Data contracts & data mesh Added

A data contract is a versioned promise from a data producer to its consumers. Data mesh is an operating model where business domains own and publish data as products, under shared rules.

๐Ÿ“ Schema

Fields, types, required or optional. Avro, Protobuf, JSON Schema or OpenAPI.

๐Ÿ“– Semantics

What each field means: "amount is in cents, AUD, including GST".

โฑ๏ธ Quality & SLAs

Freshness, completeness and availability targets, such as "lands by 6 am, at most 0.5% nulls".

๐Ÿ‘ค Ownership

Owning team, support channel, classification (see 7.2).

๐Ÿ”ข Versioning

Backward-compatible changes in place; breaking changes get a new major version and a deprecation window.

1. Domain ownership

The team that runs the business process (payments, lending) owns its analytical data too. No central team as a bottleneck.

2. Data as a product

Each dataset is a product with an owner, documentation, a contract, SLAs and users it must keep happy.

3. Self-serve platform

A platform team provides storage, pipelines, catalogue and access control as self-service, so domains don't rebuild plumbing.

4. Federated governance

Shared global rules (classification, privacy, interoperability) set together and automated in the platform; domains decide the rest.

โœ… Mesh fits when

Many domains, many data producers, a central data team that is a bottleneck, and strong platform engineering.

โŒ Mesh is overkill when

A small organisation, a handful of sources, a central team that keeps up, or domains without the skills to own data products. Data contracts alone still help.

Data fabric, in one line: a technology-led approach that uses metadata, a catalogue and automation to connect data across sources. Mesh is mainly about organisation; the two can work together.

  • Start with contracts on your most important feeds. You don't need a full mesh to get most of the benefit.
  • Enforce contracts in CI and at the registry. A contract in a wiki is just a hope.
  • Mesh changes the org chart before it changes the tech.
How to implement it
NeedLibrary / APINotes
Event contractsConfluent.SchemaRegistry + Confluent.SchemaRegistry.Serdes.Avro (or .Json / .Protobuf)Serialise Kafka messages against registered schemas; the registry enforces compatibility rules
JSON contracts for files and APIsJsonSchema.Net or NJsonSchemaValidate payloads against a JSON Schema in tests, CI and at ingestion
API contractsbuilt-in Microsoft.AspNetCore.OpenApiGenerate the OpenAPI document from your minimal APIs and diff it in CI to catch breaking changes
var registry = new CachedSchemaRegistryClient(new SchemaRegistryConfig { Url = registryUrl });

var serdeConfig = new AvroSerializerConfig
{
    AutoRegisterSchemas = false,   // only CI may register schemas, after a compatibility check
    UseLatestVersion = true        // serialise with the latest approved version
};

using var producer = new ProducerBuilder<string, PaymentEvent>(producerConfig)
    .SetValueSerializer(new AvroSerializer<PaymentEvent>(registry, serdeConfig))
    .Build();

await producer.ProduceAsync("payments.v1",
    new Message<string, PaymentEvent> { Key = payment.AccountId, Value = payment });

PaymentEvent here is a class generated from the Avro schema (e.g. with avrogen). The schema file, not the C# class, is the contract.

Most "data quality issues" are really broken promises between teams ๐Ÿค

๐Ÿ“ Data contract: schema + meaning + SLAs + owner + version

๐Ÿšซ Schema registry: breaking changes fail the build, not the dashboard

๐Ÿงญ Data mesh: domains own data as products, on a self-serve platform, with federated governance

โš ๏ธ Small org, few sources? Mesh is overkill. Contracts alone get you most of the value.

Would your team notice if an upstream field was renamed tonight?

#DataMesh #DataContracts #DataEngineering #Architecture

โšก Quick-fire Q&A

Masking vs tokenisation vs pseudonymisation vs anonymisation?

Masking hides part of the value on display; the real value is still stored. Tokenisation swaps the value for a random token that only a vault can reverse. Pseudonymisation replaces identifiers with a keyed ID; it can be re-linked, so it is still personal information. Anonymisation can't be linked back to a person, so privacy law generally stops applying, but you must test the re-identification risk.

How do you delete a customer's data when it's also in backups?

Hard-delete it in live systems (including history tables, lake files and indexes), keep a deletion log that is replayed after any restore, and let backups age out on a short, documented cycle. For a stronger guarantee, use crypto-shredding: encrypt each customer's data with its own key and delete the key. Always check legal holds and AML/CTF retention first.

We host in Australia East. Is that enough for data residency?

Not by itself. Check every copy (replicas, backups, logs, CDN, AI endpoints), keep keys in an Australian vault, block other regions with policy, and control offshore support access, which can count as a cross-border disclosure under APP 8. Residency also isn't sovereignty: the provider's home-country laws may still reach the data.

When would you not recommend a data mesh?

In small or medium organisations with few sources, a central data team that keeps up, or domain teams without data engineering skills or a self-serve platform. Start with data contracts, a catalogue and clear ownership. Move to mesh when the central team becomes the bottleneck.

โ† 06 ยท Databases & Data