Where consent usually lives
In most implementations, consent is a checkbox in a form. The user ticks it, the frontend records that they ticked it, and the verification call goes out separately. Two systems, two records, joined by the assumption that nothing happened in between.
That assumption holds right up until someone asks you to demonstrate, for one specific check on one specific date, that consent existed before the call was made. Then you are reconciling a frontend event log against an API log and hoping the timestamps cooperate.
Put it in the request
If the consent reference is a required parameter on the verification call itself, the question answers itself. The reference is in the request. The request is in the log. The response echoes it back. There is one record, and it is the record that matters.
A consent trail you have to assemble from two systems is a consent trail you will assemble under pressure.
Purpose belongs there too
Consent is not generic. Someone consenting to an identity check for a loan application has not consented to the same check being run eight months later for a marketing segmentation exercise. Recording the stated purpose alongside the reference is what makes the distinction auditable rather than arguable.
Minimise what comes back
The strongest retention policy is not retaining the data. If a decision needs a match result and a masked identifier, the response should contain a match result and a masked identifier. Full identifiers that are never returned cannot leak from a log, a backup, or a support export.
A practical checklist
Consent reference required on every identity call. Purpose recorded with it. Responses masked by default. Retention set to the shortest period your obligations allow, and configured rather than assumed. Logs that can be queried by consent reference, because that is how the question will be asked.
Written by the MuVertex team. Questions about anything here? Get in touch.