Consent Management: Recording and Proving What a Customer Agreed

A consent record is not a tick box. The record has to answer nine separate questions on its own, years later, with nobody left to explain it: who agreed, to whom, to exactly which items, for what purpose, for how long, when, by what route it can be withdrawn, under which version of the wording, and what the customer was actually looking at.

Everything a firm might later want to say about a customer's agreement has to have been captured as a field on the day it happened. Capture on the day is the whole difficulty. A screen gets redesigned, a purpose gets widened, a supplier gets swapped, a data item gets added to a form by somebody improving it. None of that is recoverable afterwards from a system that has since moved on, so anything not written down at the moment of agreement is not weakly evidenced later. The fact is simply gone.

What is a consent record actually being asked to prove?

Think about a lease on a rented flat. The tenant and the owner shake hands in the doorway and agree that the rent covers water but not the lift maintenance. Eighteen months later the building association raises a bill and the two of them remember the conversation differently, not because either is lying but because nobody wrote it down. The agreement was real. The evidence of it never existed. And notice what settles the argument when it does exist: not a signature on its own, but a document that names the two people, the flat, the charges, the start date and the end date.

A consent recordThe written evidence of what a customer agreed to, which is all that survives once the screen has changed. is that document, for data instead of a flat. The record is asked to prove not that agreement happened, but exactly what was agreed to, by whom, on what terms, and under wording somebody can still produce. The party asking is rarely the customer. The party asking is a supervisor with a question about a population of files, or an internal reviewer testing a process, or a court years afterwards, and none of the three can be answered with a recollection.

Sumeru Bank Limited, an invented retail lender, runs a loan intake chain that starts on an applicant's handset, and the consent step in that chain is step 5 of six in digital onboarding. Two separate counts come out of that step, and holding them apart is half the subject. In month 6, 300 applicants a month could not complete step 5 at all. Separately, 112 files that did complete it reached the bank's exception desk carrying an incomplete consent record. The bank files those 112 under exception cause 6. The 300 and the 112 sit at two different points in the journey and describe two different populations, and merging them produces a number that describes nothing.

What does that record have to hold, field by field?

The Consent Artefact, drawn as the nine fields it has to carry

The working set follows, numbered so that any later question can point at one without ambiguity. Each entry answers to a single test: what happens if that field is blank. The answer to that test is the whole reason the field is on the list.

Notice the pattern in the three blanks before anything else. Fields 1, 2, 3, 4, 6 and 7 all do work on the day: an application cannot be processed without knowing who applied, what is being shared, with whom and why, when it happened, and where a customer goes to stop it. Fields 5, 8 and 9 do no work on the day at all. The three of them only ever earn their keep when somebody comes back with a question. A record built by the people who have to make onboarding work will hold the six fields the process consumes and drop the three the process never reads, and that is not carelessness, it is exactly what optimising for the day looks like.

Why is a tick box not a consent record?

Because a tick is a single bit of information and the record has nine questions to answer. The point sounds obvious written down and is very hard to see on a screen. The tick box is where the customer's agreement visibly happens. The moment feels like the artefact. The moment is not the artefact: the moment is the trigger, and the artefact is whatever the system wrote to a table a fraction of a second later.

Draw the two side by side with identical geometry and the difference stops being arguable.

The tick box and the consent record are not the same thing at two levels of detail; they are an event and an artefact, and only one of them still exists next year. The event is what the customer did. The artefact is what the bank can produce. Every design conversation that goes wrong on this subject goes wrong by treating the first as evidence of the second.

Why do fields 5, 8 and 9 go missing more often than the other six?

Take them one at a time. Each is missing for a slightly different reason, and each breaks something different.

Field 5 is the retention periodHow long the data may be kept, which is field 5 and is the one most often left unstated., and it goes missing because nobody wants to commit to a number. Deciding how long an income statement may be kept means somebody has to think about the tax position, the recovery position and the operational convenience of keeping everything forever, and the easy way out of that meeting is to write nothing. The break shows up as a deletion request the bank cannot answer without opening the question it avoided, and as an inability to say whether it is currently holding anything it should not be.

Field 8 is the version stampThe identifier of the wording a customer was shown, without which no later question about wording can be answered., and it goes missing because at go-live there is only one version. A field whose only value is one constant looks like waste, and it is waste, right up until the day somebody changes the wording. The break arrives on the day somebody rewrites the wording, and it carries the largest single cost in Sumeru's record.

Field 9 is what was actually on the screen, and it goes missing because storing it feels like storing a photograph of something the bank already has. It is not. The bank has the wording it believes was live; field 9 records what this customer was actually looking at, including whether the text was behind a link they never opened or in front of them. A signature proves that somebody signed and never proves that they read. Field 9 exists as a separate field from field 8 for exactly that reason.

How is what a process consumes checked against what the customer saw?

How to Map Consent and Data-Sharing Requirements, in five ordered steps

Mapping is a procedure rather than an idea, and the order is the whole of it. The check at the end is a comparison, and a comparison needs two lists, so the list of items has to exist before anything can be checked against it.

Step 1 is duller than it sounds and harder than it sounds. The documentation and the process disagree, so listing what a process consumes means walking the process rather than reading its documentation. At Sumeru the reading step pulls fourteen fields from every file, and that fourteen is a measured count of what the chain actually takes, not a count of what a form says it takes.

Step 2 asks who holds each data itemOne named field, as distinct from a described category of fields. at its source and who is accountable for it there. Step 3 names the recipient and the purposeWhat the data may be used for, stated narrowly enough that a mismatch with the product is visible., and the discipline in step 3 is narrowness: a purpose written broadly enough to cover anything the bank might ever do cannot be breached. Being unbreachable sounds convenient and means the field has stopped doing work. Step 4 fixes the period item by item. Step 5 is the only step that compares anything, and it compares the wording on the screen against the list built in steps 1 to 4, item by name.

Why is a general phrase not a mapping?

Because a phrase covers items without naming them, and a mapping is a list of names. The gap between a phrase and a list is the single most common way a consent form passes a review it should have failed, and Sumeru's own record shows the shape of it exactly.

A general phraseWording that covers items without naming them, which reads as coverage and is not a mapping. such as the four words and related information reads as coverage. Because the phrase appears to catch everything left, a reviewer's eye slides over it. The phrase actually moves five items out of the countable list and into a place where nobody can point at them. And here is the connection that makes the phrase more than a drafting quibble. A retention period is stated against a named item, and inside the phrase there was no named item to state one against, so the five items sitting inside the phrase are exactly the five for which nobody at Sumeru could state a period.

Whatever a general phrase covers, it also hides, and what it hid at this bank was five of fourteen items with no stated period and no way to produce a list of them. The bank's own record also cannot say which five. The mapping finding records the counts and not the identities, so the fix is not a lookup, it is redoing steps 1 to 5 from the beginning.

Where does an incomplete consent record show up in a running chain?

In two places, and this is where the two counts have to be held apart. The journey matters more than the number.

Take the 300 first. The 300 are the count most easily lost. In month 6, 8,900 applicants reached step 5 and 300 of them did not complete it. The 300 are 3.4 per cent of those who got that far and 3.0 per cent of the 10,000 who started an application that month. Step 5 completed for 96.6 per cent. A step completing for 96.6 per cent sounds like a step working well. The bank's own records name the step these 300 stopped at and record no reason at all for why. The honest answer to what went wrong for them is that nobody knows. The 300 wanted the product. Every one of them got as far as the last screen before submission. Whatever the consent step asked of them at that moment, they could not give it, and because no file was ever created, not one minute of anybody's time at the bank is spent on them in any month.

The 112 are a different animal entirely. The 112 files completed step 5 and reached the decision engine, and the workflow router then sent each one to a person because the consent record attached to it was incomplete. The bank calls that routing exception cause 6. Cause 6 is 3.7 per cent of the month's 3,010 exceptions and 1.3 per cent of the 8,600 completed files. A person then had to do something about each one.

What were the 112 files actually missing?

Splitting a vague quality problem into named causes is what turns it into a change somebody can make. Sumeru split the 112 three ways.

Read the three causes as three different kinds of problem, and not as three versions of one. The 71 are a mechanical fault in how the record is written: the customer did everything asked and the session ended before the write completed, so field 6 never existed. Nothing about the wording or the customer is involved, and the fix lives entirely inside the write, in making the record durable before the session is allowed to end. The 29 are a fault in the mapping: a purpose was recorded and it described a different product. Reusing one consent wording across products at step 3 of the mapping produces exactly that. The 12 are the missing version stamp showing up as a countable exception rather than as a silent gap.

Two thirds of an apparently vague quality problem turned out to be one specific mechanical fault, and nobody could have known that from the count of 112 alone. The split is the useful artefact, not the total.

How is consent withdrawn, and who does the work?

Ask somebody who has not run an operation what a withdrawalThe customer route out, which is work for somebody rather than a setting. involves and they will describe a switch. Ask somebody who has, and they will describe four separate pieces of work, each of which somebody does.

Look at box 1 for a second longer. Box 1 connects straight back to the mapping. Finding every place the items were sent is trivial when field 3 lists the items and field 2 names the recipients, and it becomes a search when five of the fourteen items sit inside a phrase. The quality of the mapping on the day of consent decides how expensive a withdrawal is two years later. Nobody makes that connection while designing a form.

What does servicing a withdrawal cost against the capacity that exists?

Now put the four boxes against the desk that has to do them. Sumeru's exception desk runs at a measured margin of 4.2 cases a day of servicing capacityThe spare work a desk actually has, which decides whether a right can be exercised in practice. beyond the work already arriving. Over the bank's 20 working days in a month that is 84 cases, and 84 is 0.98 per cent of the month's 8,600 completed files.

An answer is worth settling on before the control below is touched.

What happens to a right the operation cannot service?

A right stops being a right and becomes a waiting list. The crossing point is nowhere near where intuition puts it, so the arithmetic is worth doing.

Read the middle row again. Under one customer in a hundred exercising a published right consumes the entire spare capacity of the desk that has to service it. At two customers in a hundred, the desk services 84 and 88 more join a queue every month. The 88 are 51.2 per cent of the people who asked, waiting rather than served, and the queue does not stabilise because nothing in the arithmetic makes it stabilise. A right the operation cannot service is not a right, and the number that decides whether it can is not the withdrawal rate on its own but the withdrawal rate set against a measured margin.

The money, for scale, and every figure in this sentence rests on an assumption the bank made rather than on anything measured. At the crossing point, 84 withdrawals at an assumed 15 minutes is 1,260 minutes a month and 15,120 minutes a year, being 0.15 of a post at the assumed working month of 8,400 minutes. At the bank's assumed fully loaded cost of Rs 9,00,000/- a post a year that is about Rs 1,35,000/- a year, set against the Rs 65,00,000/- a year the whole intake chain costs to run, so about 2.1 per cent of it. Funding it was never the obstacle. Nobody had estimated the rate, so nobody knew there was anything to fund.

What has to be recorded on the day so the answer survives?

All nine fields, and the three easiest to skip are the three that decide whether the record is worth anything in three years. There is no clever alternative to this and no way to buy the fields back later. A useful discipline when a screen is being designed: for each of the nine, ask who will ask this question, in how many years, and what they will accept as an answer. Any field where the honest answer is nobody, ever, can be dropped. In practice the answer is never that for fields 5, 8 and 9.

Two small habits do most of the work. First, write the record before the session is allowed to end rather than after. Writing it early is the whole of the fix for the 71 files with no timestamp. Second, stamp the version on every record from the first day even while there is only one version. The field costs nothing while it is a constant and cannot be added once it is not. The version stamp is worth nothing until the wording changes and cannot be created after it has. A control with that shape is the most awkward kind there is, and the awkwardness is the reason this one gets dropped.