Point-in-time replay: reconstructing a compliance decision for an exam
An exam, a look-back, or a response to a finding asks the same thing: what did you decide, on what evidence, under which rules, as of a date in the past. Answering with today's data and today's policy is not the same question. Here is how to answer it exactly.
The question a look-back actually asks
When an examiner reviews a past decision, or a finding requires you to look back over a population, the question is historical: what did you know at the time, what rules were in force, and what did you decide. The honest answer requires the state as it stood, not the state as it is now. This is where most programs reconstruct rather than reproduce, because the underlying tools are built to show current state.
Why a normal stack cannot replay
Two things drift. The signals drift: re-pulling a vendor result today returns today's answer, not the one you acted on. And the policy drifts: your rules have been tuned and revised since, so evaluating an old decision against your current policy tells you what you would do now, not what you did then. Without the signals and the policy version preserved together, a look-back becomes an estimate, and an estimate is hard to defend.
How point-in-time replay works
FinQub is the single source of truth for fintech risk decisions. Every signal, decision, and override on the record is pinned to the policy version that applied when it fired, and the signals are kept as they stood, not overwritten with later state.
Reconstruct, do not estimate. Because the record holds the historical signals and the historical rules, you can show what a decision was, on what evidence, under which policy version, as of any past date. You can also replay a prior policy version against the evidence to see what it would have decided.
The export matches the history. A signed exam packet for a past decision contains the evidence and the policy version that applied, so what you hand an examiner is the reconstruction, not a present-day approximation of it.
Frequently asked questions
What is point-in-time replay?
The ability to reconstruct a past decision exactly as it stood: the signals as they were at the time, the policy version that was in force, and the disposition that followed. It is the difference between telling an examiner what you decided and showing them, under the rules that applied then rather than the rules you have now.
Why is this hard with a normal stack?
Vendor consoles show current state, not historical state, and policies change. Re-pulling a vendor result today gives you today's answer, and evaluating against today's policy is not what you did at the time. Without the signals and the policy version preserved together, a look-back becomes an estimate rather than a reconstruction.
How does FinQub do this?
Every signal, decision, and override on the record is pinned to the policy version that applied when it fired. Because the record holds the signals as they stood and the rules as they were, you can replay any prior policy version against the evidence and show what the decision was, on what basis, as of any past date.
FinQub replays a past decision on your own vendor stack, with nothing reconstructed by hand. See how the whole record fits together, or book a short walkthrough below.