Consent architecture: consent as a structured object, not a tickbox

Why consent has to be an architecture

Most operators treat consent as a one-off act of registration: the customer signed the contract at activation — therefore agreed to everything. That worked in the era of bulk SMS, but it does not work when:

• regulation tightens (data protection law, special categories of data, biometric data),
• the number of use cases grows (CDP, fraud, scoring, partner sharing, AI training),
• partner-driven scenarios appear (bank, retailer, government services via the operator).

Modern consent is a structured object: “customer Y granted consent to use data of type X for purpose Z in channel W for period T, with the right to withdraw at moment R”.

Without a consent architecture it is impossible to:

• answer the regulator on what legal basis a specific data use was lawful,
• give the customer a transparent picture of “what you know about me and why”,
• quickly implement the right of withdrawal without breaking the whole system.

Structural elements

Consent collector. Points where consent is captured: onboarding, app, web form, contact centre. Standardised record format.

Consent registry. Centralised store of consent claims. Each record: subject (customer), purpose (specific objective), data scope (which categories), channel, validity period, source, version of consent text.

Purpose taxonomy. Controlled list of data use purposes: marketing communication, credit scoring, fraud prevention, partner sharing, product personalisation. Each purpose is a separate consent.

Consent enforcement layer. Every use of data goes through a check: “is there an actual consent for this purpose for this customer?”. No consent — the operation is blocked.

Withdrawal mechanism. The customer can withdraw consent at any moment. After withdrawal — data is not used for that purpose, downstream systems receive an update.

Audit trail. Every consent event (granted, withdrawn, expired) and every use of data under consent — logged.

Where it usually breaks

Consent exists in one system (for example, CRM as a “marketing consent” field), but other systems do not know about it — billing sends notifications, fraud shares with partners, analytics trains a model. Inconsistency is obvious.

Purpose taxonomy is not defined. “Communication consent” — what is that? Marketing? Transactional? Both? When the regulator asks, the operator cannot answer clearly.

Consent text changes but the registry stores only the latest. When checking against a past period it is impossible to show what text the customer saw.

Withdrawal is processed manually — no clear SLA, withdrawal claims get lost in queues.

Granular consent is impossible — the customer can either agree to everything or to nothing. This violates GDPR-style requirements.

Partner sharing runs under a generic “consent” without the specifics of “transfer of data to partner X for purpose Y”. When questioned — the operator cannot prove legal basis.

Key scenarios

Onboarding. New customer. Granular consent up front: marketing channels, partner sharing, profile-based personalisation. Separate ticks, not one common one.

Re-consent. When consent text changes or a new purpose appears — the customer is shown an update. Without re-consent — old data is not used under new purposes.

Withdrawal flow. The customer can per-purpose withdraw consent in the app. The change is pushed to downstream systems within minutes.

Subject access request. The customer asks what the operator knows. The consent layer shows the purposes data was used for.

Data deletion. The customer leaves — after the legal retention period, data is deleted across all purposes.

Operating model

Owner — DPO (Data Protection Officer) with a tech mandate, or Head of Data Governance.

Teams:

• Platform engineering (consent registry, enforcement, APIs)
• Compliance / Legal (purpose taxonomy, consent text, regulator interface)
• Channel integration (where we collect consent, how we enforce)
• Customer experience (UX of consent collection and withdrawal)

Routine — quarterly consent audit, monthly review of withdrawal patterns, semi-annual review of the purpose taxonomy.

What is measured

Consent coverage per purpose — what share of the base has consent for each purpose.

Withdrawal rate — how many withdrawals per month, by which purpose, what trends.

Time to enforce withdrawal — how long it takes from withdrawal to actual cessation of use.

Audit compliance — what share of use cases has a corresponding consent claim.

How SamaraliSoft engages

Consent Blueprint — 6-8 weeks. Inventory of current consent practice, gap analysis vs the regulator, purpose taxonomy design, target architecture, governance framework, platform choice (build / OneTrust / TrustArc / cloud-native). Pilot — usually one use case (for example, marketing communication) with migration of existing consents.

Related

• /en/architecture/telecom-cdp-architecture/ — CDP with consent enforcement
• /en/architecture/telecom-notification-fabric/ — notification fabric with consent gate
• /en/insights/telecom-data-protection/ — data protection law
• /en/architecture/telecom-data-clean-room/ — clean room