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.
How do you reconstruct why a customer was approved months or years ago?
With point-in-time replay: the signals as they stood, pinned to the policy version in force, replayed as of the decision date. Re-pulling vendor results today answers a different question, because both the data and your rules have changed since. Replay shows what was known, what rule applied, and what was decided, 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.
Worked example: a PayFac's sub-merchant underwriting decision, 14 months later
A sub-merchant you boarded 14 months ago has become a chargeback problem, and your acquirer asks the obvious question: why was this merchant approved? The honest answer lives in the past. At boarding, the KYB result was clean, the MATCH inquiry returned no hit against the list state as of that day, the fraud score was under your threshold, and underwriting policy v41 auto-approved on those facts. Since then, the KYB vendor has re-verified twice, the fraud model has been retuned, and your policy is on v48.
Without replay, the team re-pulls today's vendor results and argues from memory about what the policy said last year. With replay, the answer is the boarding-day record: the signals as they stood, the policy version that fired, the auto-approval it produced, on a signed export. The acquirer gets a reconstruction, not a re-estimate, and the conversation moves from “defend your judgment” to “here is the record.”
Worked example: a sponsor bank's exam sample
An examiner samples a customer at one of the bank's fintech partners: approved 19 months ago, exited last quarter. The question has three layers: what did the partner know at approval, what did the bank's oversight see, and did the controls that applied then actually fire. The approval predates two policy revisions and a KYC vendor switch, so every console involved now shows different data than the decision was made on.
Replay answers all three layers from the record: the approval as it stood (signals, policy version, disposition), the oversight KRIs the bank held on that partner at the time, and the escalation trail when the customer later drifted. The bank can also replay its current policy against the historical evidence to show the examiner what today's controls would have done, which is the difference between a finding and a demonstration of a tuned program.
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.
Can I reconstruct a sub-merchant underwriting decision for my acquirer or sponsor bank?
Yes, that is the canonical use. The boarding-day record holds the KYB result, the MATCH inquiry against the list state as of that day, the fraud score, and the underwriting policy version that auto-approved or escalated. A signed export of that record answers 'why was this merchant approved' with the facts that were true at boarding, not today's re-pull.
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.