FenoriTechnologies
Selected Builds

Back-Book Assurance

The past should remain examinable.

We built Back-Book Assurance: a system that applies new intelligence and improved capability to historical activity, surfaces the prioritized subset of cases where something meaningful has changed, and preserves the context in which the original decisions were made.

StatusReference architecture
Institutional problemThe closed book goes dark as new information arrives
Technical foundationRetrospective analysis, change-triggered scoping, prioritization, historical reconstruction
Existing systems retainedHistorical data stores and case records
Human authorityHuman review determines findings and action
Evaluated onCandidate precision, coverage of triggering change, context fidelity
DemonstrationArchitecture walkthrough on request
DataSynthetic
DeploymentInstitution-governed AWS environment
TypeAssurance systemDomainFinancial servicesStatusReference architectureComponents6

The institutional problem: the closed book goes dark.

A closed case is not a permanently understood case. Intelligence appears, sanctions lists change, ownership becomes visible, detection improves, and regulators ask institutions to look back.

Without infrastructure, a look-back is an undifferentiated manual search across years of activity, and it dangerously blurs two questions: what can we see now, and what could the institution reasonably have seen then.

Inputs and source systems.

The system operates against historical institutional data, not only the activity arriving today.

  • The historical book: transactions, customers, relationships, closed alerts and cases, previous decisions
  • New information: listings, ownership, intelligence, improved models, policy triggers

How the system is composed.

What happens when an event enters.

Historical bookTransactionsCustomersRelationshipsClosed alertsClosed casesPrevious decisions
↓
New information or improved capabilityListingsOwnershipIntelligenceModelsPatternsPolicy triggers
↓
Retrospective analysis
↓
Prioritized candidates
↓
Reconstruct historical state
Evaluate new information
↓
Human review and action where warranted

Core technical components.

  • Retrospective analysis over the historical book
  • Change-triggered review scoping
  • Candidate prioritization
  • Historical-state reconstruction
  • Evidence retrieval
  • Human authority layer

Scoping and prioritization logic

Some retrospective work is tied to a specific event: a list change, a newly visible ownership relationship, a counterparty becoming high risk. The system scopes the affected part of the historical book from the triggering change, rather than beginning a broad review from scratch.

The objective is never to reopen everything. Analysis narrows the historical population to the cases where new information or stronger analysis creates a genuine reason for another look, ranked by how materially the picture has changed. The rest of the book stays closed, with the reasons on record.

Example: a sanctions designation hits the back book.

A sanctions authority designates a set of entities including Kavkaz Terminal LLC. The institution must understand its historical exposure, not just screen tomorrow’s activity. Entities and figures in this walkthrough are synthetic.

  1. The designation triggers a retrospective pass scoped to the relevant corridors and counterparty networks in the historical book.
  2. Analysis identifies intersections between the designated entities’ ownership networks and historical activity that was clean when originally reviewed: including two closed cases from 2023.
  3. The affected population is narrowed to nine reopen candidates, ranked by how materially the picture has changed.
  4. For each candidate, the original decision context is reconstructed next to the new designation: what was knowable at closure, and what the designation changes.
  5. Human review confirms two findings and routes them to remediation; the remaining seven are closed again with the comparison on record.

How it sits inside the institution.

Evidence and audit behavior

For every candidate, the original decision context is reconstructed alongside the new information: what was knowable then, next to what is visible now. A look-back conducted this way preserves the historical record instead of overwriting it with hindsight.

Where human authority remains

A retrospective signal is not automatically a finding. Human review determines which candidates constitute findings and what action follows.

Working with what already exists

Back-Book Assurance reads the institution’s existing historical data and case records; findings route into the institution’s normal investigation and remediation workflows.

What the system outputs.

  • A prioritized, ranked set of reopen candidates with the reason each qualified
  • Side-by-side reconstruction: original decision context against new information
  • A documented basis for the cases that remain closed

What it deliberately does not do.

  • It does not reopen everything: the objective is the subset of history where something meaningful has changed.
  • It does not declare previous decisions wrong because technology has improved; what was knowable then is preserved and respected.
  • A retrospective signal is not automatically a finding: human judgment determines what new information means and what action follows.

Closing a case should not mean losing the ability to understand it again.

Related builds

Built around your problem, not this one.

An institution may need this build, part of it, or something entirely different. The institution determines the outcome. The technology follows.

Discuss this outcome