The first question in a vendor review is rarely “do you capture consent.” Almost everyone captures consent. The question is closer to: show me the permission that authorized this specific inquiry, and the exact text the consumer saw when they gave it.

That is a harder question than it looks, and the gap between the two is where most remediation work lives.

What a checkbox actually stores

The common implementation stores a boolean on the applicant record. Maybe a timestamp beside it. It answers “did this person consent” with a yes.

Now run the review questions against it:

  • Which version of the disclosure was displayed? Unknown — the copy has been edited twice since.
  • Did they consent to a qualification inquiry or an application inquiry? The column does not distinguish.
  • Which of the three inquiries on this file did that consent cover? All of them, apparently.
  • Was consent still current when the third one ran, eight months later? Unanswerable.

The boolean is not wrong. It is just not evidence.

The structural fix is small and it is worth making early, because retrofitting it means backfilling records that cannot be reconstructed.

Treat each grant of permission as an immutable event with its own identifier, carrying at minimum:

  • the identity of the consumer as resolved at that moment
  • the disclosure version presented, by content hash or version id — not by reference to “the current disclosure”
  • the scope: what kind of inquiry, for what purpose
  • when it was captured, and through which surface
  • the context available at capture: session, channel, and the presentation method

Then have the inquiry reference the consent event id. Not the applicant id — the consent event id. That single indirection is what turns “this person consented at some point” into “this inquiry was authorized by this permission.”

Version the disclosure, not just the record

The subtle failure is storing a pointer to the disclosure by name. terms_v2 is fine until someone edits terms_v2 in place to fix a typo, and now every record that points at it claims the consumer saw text they did not see.

Store the disclosure content itself, or a hash of it, alongside the event. Storage is cheap. Reconstructing what a page said fourteen months ago from a CMS’s revision history is not.

The same logic applies to anything presented with the disclosure that affects its meaning — the surrounding heading, the button label the consumer clicked. “I agree” under one heading is a different act than the same words under another.

Immutability is the point

Consent events should be append-only. If permission is withdrawn or superseded, that is a new event that references the prior one — not an update to it.

This matters because the interesting review questions are historical. Nobody asks what the current consent state is; they ask what it was on the date of the inquiry under discussion. A mutable record answers the first question and destroys the second.

An append-only log also makes withdrawal tractable. Withdrawal is a real event with a real timestamp, and downstream systems need to be able to ask “was permission current at time T,” which is a query over a log and an impossible question against a flag.

Attach it to the whole journey, not just the pull

The scope of a consent record tends to be drawn too narrowly — around the credit inquiry alone. But the same permission usually underwrites what happens after: the decision that consumed the data, the event dispatched to a downstream system, the record retained for a retention period.

If the consent event id travels with the workflow rather than stopping at the inquiry, then the audit trail for a decision includes the permission that made the inputs available. That is one join instead of a reconstruction project.

This is the design intent behind consent-aware workflows in Revery Credit: the permission event stays connected to the inquiry and to what the inquiry feeds, rather than being captured at the front door and forgotten.

What we are not saying

Nothing above is a compliance opinion about your program, and none of it is a substitute for one. FCRA obligations, state-level requirements, disclosure language, and retention periods depend on your product, your jurisdiction, and your permissible purpose. Your legal and compliance teams own those decisions, and a platform’s design can support their conclusions but cannot stand in for them.

What we will say is narrower and, we think, uncontroversial: the difference between a system that can answer review questions and one that cannot is usually a data model decision made in the first month, not a control added in the eighteenth.

Model consent as an event. The rest is much easier from there.