Updated At Apr 18, 2026

DPDP Act RBI Digital Lending Co-Lending 11 min read

Co-Lending Consent Chain: From Lead Source to NBFC to Bank

How Indian banks, NBFCs, and fintech lenders can design a DPDP- and RBI-aligned consent “supply chain” for co-lending without degrading customer experience.
Key takeaways
  • Treat co-lending consent as a shared “supply chain” from lead source to NBFC to bank, not as isolated screens inside each system.
  • Map who is acting as data fiduciary or processor at every stage, and align contracts, APIs, and logs so that consent is provable in audits and disputes.
  • Design a unified, queryable consent ledger and revocation flows that propagate reliably across all co-lending partners without breaking customer experience.
  • Choose a consent architecture (centralised, federated, or platform-based) using clear evaluation criteria: audibility, latency, partner integration effort, and DPDP/RBI alignment.
  • Run co-lending consent as an ongoing program with defined ownership, SLAs, and KPIs, not a one-time compliance project.

Why co-lending makes consent governance uniquely complex in Indian BFSI

Co-lending has moved from pilots to scale in India, with fintech lead sources, NBFCs, and banks jointly originating loans on shared balance sheets. That creates a dense web of data flows, decisions, and responsibilities that all depend on one fragile foundation: the borrower’s informed, traceable consent.
For senior leaders, the risk is no longer just “do we have a consent checkbox on the app?” but “can we prove, to a regulator or board committee, exactly what the borrower agreed to, for which purposes, at each hop from lead source to NBFC to bank?” If the answer is unclear, you have a consent-chain problem.
Key factors that raise the stakes for consent governance in co-lending:
  • Multi-entity journeys, where lead generators, NBFCs, banks, collection partners, credit bureaus, and insurers all touch the same borrower data.
  • Fragmented technology stacks: different LOS/LMS platforms, CRMs, mobile apps, IVR systems, and data lakes across each regulated entity and outsourcing partner.
  • Ambiguous accountability, where it is unclear in practice who is the data fiduciary versus a processor for a given purpose, and who must evidence consent if there is a complaint or investigation.
  • High downside risk: inability to quickly reconstruct consent can slow down regulatory queries, increase dispute rates, and expose the institution to penalties and reputational damage.

Mapping the end-to-end consent chain from lead source to NBFC to bank

Before you re-architect anything, you need a shared view of how consent actually flows today. That means decomposing the co-lending journey into stages and documenting who collects consent, what is disclosed, which data moves where, and how revocation (if any) is enforced.
A practical way to map your current co-lending consent chain:
  1. Inventory co-lending products and partners
    List every loan product that uses co-lending and the regulated entities involved (banks, NBFCs, fintech LSPs, outsourcing vendors). Note which brand is customer-facing and whose terms and conditions are presented.
    • Capture whether each journey is app-led, web-led, assisted, or branch-led.
    • Record which entity manages each key system: LOS, LMS, mobile app, CRM, collections platform.
  2. Trace data elements and purposes across the journey
    For each stage, list the personal data collected or accessed (identity, KYC, bureau data, device data, bank statements, contact lists, etc.) and the specific purposes (eligibility check, underwriting, KFS delivery, collections, cross-sell, analytics).
    • Flag sensitive or high-risk data (e.g., financial, biometric, precise location) for extra scrutiny.
  3. Catalogue consent capture points and artefacts
    Document every point where you rely on consent: checkboxes, OTP-based agreement acceptance, digital signatures, call recordings, chat transcripts, consent obtained by DSAs or call centres, and any offline forms scanned into systems.
    • Record the exact consent text, notice wording, and version used at each point.
    • Capture which system stores the primary artefact (e.g., LOS database, document store, voice logger).
  4. Map consent storage and propagation paths
    Track how consent data or flags are written into each system, how they are shared across NBFC and bank, and where data is replicated into warehouses or third-party systems. Identify any manual steps or spreadsheets used to reconcile consent states.
    • Highlight mismatches where one entity assumes consent exists but cannot see or verify the artefact.
  5. Validate the consent map with legal, compliance, and partners
    Walk the end-to-end map with internal legal/compliance, the DPO, and partner NBFC/bank teams. Confirm who is the data fiduciary or processor at each stage and whether the current consent and disclosures align with contractual and regulatory expectations.
    • Use this review to identify immediate control gaps and prioritise fixes before large-scale remediation.
Illustrative view of how consent, roles, and audit artefacts span a co-lending journey.
Journey stage Typical activities Primary data fiduciary Other key parties Consent / notice focus Audit artefacts to retain
Lead generation and marketing Ads, referrals, marketplaces, and aggregator platforms capture leads and initial interest; basic identity and contact data collected. Typically the bank or NBFC whose product is being promoted, if it determines purposes and means of processing the lead. Fintech LSPs, DSAs, marketplaces, and ad networks that facilitate the lead flow. Consent for contacting the customer, using data for pre-qualification, and sharing with specifically named lenders rather than vague “partners”. Screenshots of lead forms, consent text and version, timestamped logs, campaign identifiers, and referrer details.
Pre-qualification and eligibility checks Soft checks, basic KYC, and rule-based eligibility assessments; sometimes with light-weight bureau or account-access data pulls. Usually the NBFC if it is performing the first level of underwriting and owns the LOS for early stages, subject to contract and disclosures. Lead-source fintech, bank partner (if already identified), KYC providers, bureau gateways, account aggregators if used. Consent and notice for KYC and eligibility checks, including any bureau or bank-statement access and the identity of the entities accessing that data. KYC consent logs, bureau pull logs, AA consent handles where applicable, with journey IDs linking back to the original lead.
Underwriting and risk assessment in co-lending Full-file underwriting including bureau, bank statements, device data, employment data, and internal/external scores; allocation of loan shares between NBFC and bank. Both NBFC and bank are typically data fiduciaries for core underwriting uses, since both determine how borrower data is used for joint lending decisions under the co-lending arrangement. Bureau providers, analytics vendors, fraud engines, account aggregators, and other LSPs involved in underwriting. Clear consent and disclosures for sharing data between NBFC and bank, and for using that data for joint underwriting and portfolio monitoring, consistent with co-lending directions requiring both REs to retain a meaningful share of each loan and responsibilities to the borrower.[5] Underwriting rules, scorecards and logs, system notes, and a traceable link from each data pull to the consent under which it was performed.
Sanction, documentation, and agreement acceptance Issuing sanction letters, presenting the Key Fact Statement, executing digital or wet-signed agreements, and capturing acceptance or signatures. The entity that is customer-facing for the loan (often NBFC or bank, depending on the model) and issues the KFS and loan agreement is typically the primary fiduciary for this stage, alongside the co-lender. Digital document providers, eSign platforms, LSPs supporting KFS display and communication, contact-centre partners explaining terms. Explicit consent to the final loan terms, co-lending structure, sharing of data between lenders, and any optional products (insurance, cross-sell). Executed agreements, KFS versions, timestamps and channel data for acceptance, and call recordings or chat logs where terms were explained.
Disbursal and onboarding to servicing systems Fund disbursal from the NBFC and bank, creation of loan accounts, onboarding to servicing and customer service channels, and first communications to the borrower. Each regulated entity funding the loan acts as a data fiduciary for its share of servicing and reporting obligations, as set out in the co-lending agreement and regulatory directions. Payment gateways, disbursal banks, servicing system providers, notification gateways (SMS, email, app push), and customer support platforms. Disclosures on how contact details and transaction data will be used for servicing, collections, regulatory reporting, and service communications, and how to opt out of non-essential marketing. Disbursal logs, system-of-record entries, notifications sent, bounce reports, and preference settings for marketing or informational messages.
Servicing, collections, and analytics Routine servicing, collections outreach, restructuring, and portfolio analytics; potential use of third-party collectors, dialers, and communication platforms. Both co-lenders continue as data fiduciaries for servicing and collections uses aligned with the original contract and regulatory expectations. Collection agencies, call-centre vendors, messaging platforms, credit bureaus, and analytics vendors supporting portfolio analysis and risk modelling. Notices and consents covering use of data for collections, bureau reporting, and analytics, and clear separation between required servicing communications and optional marketing or cross-sell contact. Dialer logs, call recordings, message templates and versions, bureau reporting files, and data-sharing logs with third-party collectors and analytics providers.

Regulatory anchors for the consent chain: DPDP Act, Digital Lending Directions, and Co-Lending Directions

Your co-lending consent chain sits at the intersection of India’s data-protection regime and sectoral regulation. Any architecture or vendor choice has to make sense against three pillars: the DPDP Act and Rules, RBI’s Digital Lending Directions, and RBI’s Co-Lending Directions.
At a high level, these frameworks drive concrete design constraints:
  • DPDP Act 2023 and its Rules govern processing of digital personal data in India. They define data fiduciaries and data principals, establish consent as the default legal basis for processing, require purpose limitation, reasonable security safeguards, clear and itemised notices, withdrawal mechanisms, and retention controls, and provide for registered Consent Managers who can help individuals manage consent across entities.[2][3][4]
  • RBI’s Digital Lending Directions 2025 set the framework for digital lending journeys, including obligations on regulated entities and lending service providers around key fact statements, digital loan documentation, explicit borrower consent for data access, and transparent privacy and data-sharing practices in digital interfaces.[7]
  • RBI’s Co-Lending Arrangements Directions 2025 unify earlier guidance, define co-lending arrangements and the roles of originating and partner regulated entities, require each regulated entity to retain at least 10% share of individual loans, set norms for customer interface and disclosures, and prescribe documentation, audit, and reporting expectations for co-lending portfolios.[5][6]
Translating regulatory obligations into consent-chain design constraints.
Topic Regulatory anchor(s) Consent-chain design implication
Lawful basis and purpose limitation DPDP Act and Rules; RBI Digital Lending Directions; Co-Lending Directions for joint lending purposes. For each borrower-level data category, define the lawful basis (typically consent) and specific purposes, and ensure both NBFC and bank only use the data within those purposes unless fresh consent is obtained or another lawful basis applies.
Notice, transparency, and disclosures to borrowers DPDP Act notice requirements; RBI Digital Lending Directions on KFS, digital documentation, and communication; Co-Lending Directions on customer interface and disclosures. Standardise notice templates and consent text across journeys so that borrowers see clear, plain-language explanations of who is lending, how their data will be used and shared, and how they can exercise rights or raise grievances, regardless of channel.
Data sharing, outsourcing, and LSP oversight DPDP Act on processors and data sharing; RBI Digital Lending Directions on LSPs; Co-Lending Directions on arrangements between regulated entities. Model data flows and consent dependencies into co-lending and outsourcing agreements, ensure only consented data is shared, and implement monitoring so that LSPs and partners access and process data strictly within agreed purposes and retention limits.
Data principal rights, grievance redressal, and auditability DPDP Act on rights and grievance mechanisms; RBI frameworks on customer protection, complaints, and audit trails in lending and co-lending. Ensure you can quickly reconstruct a borrower’s consent history and data-use trail across NBFC and bank systems when handling rights requests, complaints, or supervisory queries, with clear ownership for responses and remediation.

Designing an auditable, customer-first consent architecture for co-lending

A robust co-lending consent architecture starts from a simple idea: there should be a single, queryable truth about what each borrower consented to, when, through which channel, and for which purposes, even though multiple entities and systems participate in the journey.
In practice, that usually means implementing an enterprise consent ledger or gateway that sits close to your orchestration layer, exposes APIs and events for all capture points, normalises consent into a common schema, and writes immutable consent events that can be replayed for audits. Security safeguards and retention controls should align with DPDP requirements so you can demonstrate that notices, consents, and processing activities met statutory standards and that data is not kept longer than necessary.[2][4]
A concise checklist to structure architectural decisions:
  1. Clarify controller and processor roles across entities
    For each purpose (e.g., underwriting, collections, analytics, marketing), agree which entity is acting as data fiduciary and which as processor or sub-processor, and document this in co-lending and outsourcing agreements and internal registers.
  2. Choose a consent authority model: centralised, federated, or hybrid
    Decide whether one entity will operate the authoritative consent ledger for the co-lending program, whether each entity keeps its own ledger with synchronisation mechanisms, or whether you will adopt a third-party consent platform as a neutral layer.
  3. Define a canonical consent data model and identifiers
    Standardise how you represent consent: subject identifiers, purposes, data categories, legal bases, channels, timestamps, versions of notices, and expiry or retention policies. Align it with your enterprise data model so it can join to LOS, LMS, CRM, and data warehouse records cleanly.
  4. Integrate capture, decisioning, and propagation flows
    Make consent checks and writes part of the happy path in every journey: API calls from apps and web, assisted channels, and batch processes should all resolve to the same consent authority and propagate updates to NBFC and bank systems in near real time.
  5. Plan for reporting, monitoring, and incident response
    Build dashboards and reports that let you answer board- and regulator-level questions (e.g., consent coverage, revocation SLAs, exception rates) and support investigations or incident response when something goes wrong in the consent chain.
Comparing consent-architecture patterns for co-lending programs.
Architecture option Description Strengths in co-lending Key risks / dependencies Best suited when…
Central enterprise consent ledger owned by one regulated entity One entity (often the originating NBFC or bank) operates a consent ledger and APIs that all journeys and partners call for capture and checks. Single source of truth, simpler reporting and audit response, easier to enforce consistent notice and consent logic across channels and products. Requires strong governance and trust from co-lending partners; potential single point of failure; may need complex integrations into partner stacks and contracts to reflect roles and responsibilities. You are the primary orchestrator of co-lending journeys and already operate core digital assets and middleware used by partners.
Federated consent ledgers with synchronisation between entities Each regulated entity maintains its own consent store and APIs, and the co-lending arrangement defines how consent states (including revocations) are synchronised across them in near real time. Respects each entity’s autonomy and existing stacks; can be more acceptable where both co-lenders are large institutions with established platforms and controls. More moving parts; higher risk of inconsistent consent if synchronisation fails; harder to provide a single audit view without additional aggregation or reporting layers. Both co-lenders have significant technology capability and want to retain their own consent systems while collaborating via well-governed APIs and SLAs.
Third-party DPDP-focused consent management platform as shared layer A specialised consent management SaaS platform provides APIs, SDKs, dashboards, and reports for capturing, storing, and querying consent across journeys, acting as a neutral layer between NBFC and bank systems. Accelerates implementation with a pre-built consent data model, real-time tracking, audit trails, and reporting; can simplify multi-language, multi-channel UX and central governance across products and partners. Requires due diligence on DPDP alignment, security, uptime, and data residency; still needs strong contracts, configuration, and process discipline to achieve compliance outcomes. You want to avoid building and maintaining a custom consent platform and prefer an API-first, configurable solution that can serve multiple business lines and partners.

Where a DPDP-focused consent platform can help

Digital Anumati

Digital Anumati is a DPDP Act–compliant consent management solution that helps organisations implement structured consent governance, real-time visibility into consent status, and...
  • Designed specifically around the DPDP Act, with structured consent governance and real-time tracking of consent status...
  • Provides system-generated audit trails and regulatory-ready reports to help evidence consent and data-use decisions to...
  • API-first architecture with plug-and-play SDKs, making it easier to connect apps, LOS/LMS platforms, and other BFSI sys...
  • Enterprise-grade, “zero-compromise” security posture with claims of 99.
  • Supports 22 Indian languages, helping make consent notices and preferences accessible across India’s linguistic diversi...
Explore Digital Anumati
In a co-lending context, a platform like Digital Anumati can play the role of a shared consent gateway: capturing consent through multi-language screens and SDKs, tracking consent changes in real time across systems, and generating audit trails and regulatory-ready reports through an API-first architecture. These capabilities can materially shorten time-to-implementation compared with building a bespoke platform, but they still need to be embedded in sound governance, contracts, and configurations to support compliance outcomes.[1]

Troubleshooting consent-chain breakdowns in co-lending journeys

Common issues and practical fixes you should expect when hardening your consent chain:
  • Symptom: One partner’s LOS shows “consent available” but the other partner cannot see or validate the artefact. Fix: Treat consent status as a shared service, not a local flag. Make all systems call a common consent authority and block critical workflows when evidence is missing.
  • Symptom: A borrower revokes marketing consent with the bank, but still receives promotional messages sent via the NBFC or LSP. Fix: Implement event-driven revocation, where revocation is published as an event that all co-lending partners and channels must consume within a defined SLA.
  • Symptom: Consent text and privacy notices differ across app, web, and assisted journeys. Fix: Centralise notice templates and versioning, and make front-end channels render from the same controlled library rather than duplicating text in each application codebase.
  • Symptom: Audit teams cannot reconstruct consent state “as of” a historical date for a customer complaint or regulatory query. Fix: Move from static flags to event-sourced consent records with immutable logs and effective-from / effective-to timestamps per consent grant or withdrawal.
  • Symptom: Collections vendors rely on old data extracts that ignore updated consent preferences. Fix: Tighten controls on data exports, move to API-based access wherever possible, and require vendors to check consent status dynamically before outreach.

Operating model, KPIs, and rollout roadmap for regulated finance teams

Technology choices alone will not make your co-lending consent chain robust. You need clear accountability (DPO, CRO, CIO/CTO, business heads), structured SLAs with partners, and a roadmap that upgrades controls across products without stalling growth or customer experience.
Representative KPIs and metrics to track at program and board level:
  • Consent coverage: Percentage of active co-lending journeys where all consent capture points are integrated with the central ledger or authority, and consent artefacts are queryable within seconds.
  • Audit readiness: Median time to produce complete consent and notice evidence for a given loan account when requested by internal audit, the board, or a regulator.
  • Revocation SLA: Average and 95th-percentile time from borrower revocation (for marketing or specific processing purposes) to enforcement across all co-lending partners and channels.
  • Exception and complaint rate: Number of consent-related complaints or exceptions per 10,000 co-lending loans, and percentage resolved within your internal TAT thresholds.
  • Change-control discipline: Share of production releases involving customer data that pass consent- and notice-related checks (e.g., approvals by DPO/compliance) before go-live.
A phased rollout roadmap that balances regulatory urgency with delivery reality:
  1. Select 1–2 flagship co-lending journeys as pilots
    Pick journeys with material volumes and cooperative partners, where you can get executive sponsorship on both NBFC and bank sides, and where current consent gaps are known pain points.
  2. Define the unified consent schema, ledger, and control objectives for pilots
    Lock down the consent data model, target architecture (central, federated, or platform-based), target SLAs for capture and revocation, and reporting requirements. Align these with your DPDP and RBI implementation roadmap.
  3. Integrate front-ends, LOS/LMS, and data platforms for pilot journeys
    Wire up mobile apps, web flows, assisted channels, LOS, and LMS with the consent authority. Start with forward flows (capture and use) and then add revocation and change-of-purpose handling where feasible.
  4. Harden monitoring, exception handling, and governance rituals
    Introduce weekly/monthly dashboards, exception reviews, and joint NBFC–bank forums to review consent-chain issues, remediation actions, and customer complaints for the pilot journeys.
  5. Scale to additional co-lending products and partners in waves
    Once pilots stabilise, add more co-lending products and partners in planned waves, reusing your consent schema, APIs, and dashboards. Use each wave to refine templates and playbooks rather than reinventing the approach.

Patterns that commonly go wrong in co-lending consent programs

A few recurring anti-patterns worth calling out explicitly:
  • Designing consent purely as a UX/copywriting exercise rather than as a data, API, and contract design problem that spans NBFCs, banks, and LSPs.
  • Assuming the lead source’s generic consent automatically covers all downstream data uses by NBFC and bank, without clearly naming entities, purposes, and data categories.
  • Ignoring revocation and change-of-purpose scenarios during design, leading to brittle workarounds and inconsistent enforcement when borrowers exercise their rights later.
  • Failing to version consent text and notices, making it hard to prove exactly what a borrower saw at the time of agreement when disputes arise.
  • Treating the consent-chain initiative as a one-off compliance project rather than an ongoing capability with dedicated ownership, funding, and KPIs.

Common questions about co-lending consent chains

FAQs

A co-lending consent chain is the end-to-end trail of how borrower consent is obtained, stored, shared, and enforced across all entities in a co-lending arrangement—from the initial lead source through the NBFC and bank, into servicing, collections, and analytics.

Compared with a single-lender digital journey, co-lending involves multiple regulated entities jointly determining purposes and means of processing, and often several LSPs. That makes role clarity, consent versioning, and cross-entity propagation far more critical than in generic digital lending.

Under the DPDP framework, the entity that determines the purposes and means of processing is generally the data fiduciary, while those processing on its behalf act as processors. In co-lending, both NBFC and bank are commonly data fiduciaries for core lending uses, while fintech lead sources or LSPs may act as processors or separate fiduciaries for their own marketing and analytics activities.

Rather than relying on generic labels, treat this as a design and contracting question: for each purpose, explicitly document who is the fiduciary, who is the processor, and how this is reflected in consents, notices, and co-lending or outsourcing agreements, with validation by legal and compliance teams.

Treat revocation and change-of-purpose as first-class events, not exceptions. Your consent architecture should publish revocation events to all interested systems and partners, with clear SLAs for when each must stop specific processing activities (e.g., marketing, certain analytics, or optional data sharing).

Practically, this means: designing APIs and queues for revocation, updating downstream caches and data marts, updating preferences in communication tools and vendor systems, and having reports and alerts to detect when processing continues despite revoked consent.

No. A platform can standardise consent capture, tracking, and reporting and make it easier to operate at scale, but compliance is ultimately about decisions made in governance, design, contracts, operations, and culture. Regulators will look at outcomes—how data is actually used and protected—not just which tools are deployed.

Use a consent platform as part of a broader privacy and conduct risk program with board oversight, periodic audits, training, and continuous improvement, and seek legal advice for interpreting specific regulatory requirements.

Boards and supervisors tend to care about a mix of coverage, timeliness, and customer outcomes. That translates into metrics such as consent coverage across journeys, time to produce evidence, revocation SLAs, consent-related complaint and incident rates, and the effectiveness of remediation actions after issues are identified.

Consider packaging these into a regular dashboard or MIS pack on data protection and digital conduct risk, so that the board and senior management can track the maturity of your consent chain alongside credit, market, and operational risks.

If you are mapping your co-lending consent chain ahead of DPDP enforcement, consider scheduling a short consultation and live demo with Digital Anumati to see how structured consent governance, real-time tracking, and audit-ready reporting could fit into your NBFC–bank architecture.
Sources
  1. Digital Anumati – DPDP Act Compliant Consent Management - Digital Anumati
  2. The Digital Personal Data Protection Act, 2023 - Government of India
  3. Notice Management under the Digital Personal Data Protection Act, 2023 - Data Security Council of India (DSCI)
  4. India Digital Personal Data Protection Act and Rules – Business Overview - EY India
  5. Reserve Bank of India (Co-Lending Arrangements) Directions, 2025 - Reserve Bank of India (republished via FIAFA)
  6. Overview of RBI (Co-Lending Arrangements) Directions, 2025 - SCC Online
  7. Digital Lending in India: A Regulatory Reset under the RBI (Digital Lending) Directions, 2025 - LexOrbis

Related pages

Updated At Apr 18, 2026

Consent Logging for Regulated Financial Services

A business-style article for technical evaluators about consent logging for regulated financial services, aimed at regulated finance teams balancing customer

 Updated At Apr 18, 2026

RBI vs DPDP: Erasure When KYC Retention Still Applies

A business-style article for decision-makers about rbi vs dpdp— erasure when kyc retention still applies, aimed at regulated finance teams balancing customer

 Updated At Apr 18, 2026

Insurance Journeys: Consent for Underwriting, Wellness, and Marketing

A business-style article for business buyers about insurance journeys— consent for underwriting, wellness, and marketing, aimed at regulated finance teams

 Updated At Apr 18, 2026

Data Processors vs Data Fiduciaries: Operational Responsibilities Explained

A business-style piece for business buyers that explains data processors vs data fiduciaries— operational responsibilities explained and turns policy

 Updated At Apr 18, 2026

Consent Token vs JWT: Designing Permission-Aware Systems

A business-style technical guide for technical evaluators that covers consent token vs jwt— designing permission-aware systems, implementation details, and the

 Updated At Apr 18, 2026

What Evidence Do You Need to Defend Consent before the DPB?

A business-style piece for decision-makers that explains what evidence do you need to defend consent before the dpb and turns policy requirements into an

 Updated At Apr 18, 2026

How to Map Data Flows Before Implementing a Consent Platform

A business-style technical guide for technical evaluators that covers how to map data flows before implementing a consent platform, implementation details, and

 Updated At Apr 18, 2026

Webhooks for Consent Withdrawal and Downstream Sync

A business-style technical guide for technical evaluators that covers webhooks for consent withdrawal and downstream sync, implementation details, and the

 Updated At Apr 18, 2026

Handling Offline Consent and Assisted Sales Journeys

A business-style technical guide for technical evaluators that covers handling offline consent and assisted sales journeys, implementation details, and the

 Updated At Apr 18, 2026

Consent Receipts: What to Store, Hash, and Timestamp

A business-style technical guide for technical evaluators that covers consent receipts— what to store, hash, and timestamp, implementation details, and the