An analytics dashboard showing distribution charts on a monitor
Product / 04Working prototypes · Seeking a pilot bank

Customer Protection Platform

Harm is rarely a single event. It is a sequence that no one was positioned to see whole.

Three modules for retail and commercial banking, each built on signals the institution already generates and rarely reads together: how a customer's identity profile is changing, what surrounds an instruction still in flight, and what forward obligations the customer has already taken on. Each deploys on its own. All three share one model of evidence.

Built for

Retail and commercial banks, payment institutions, and fraud and financial-crime operations teams

Pilot scorecard

Intervention precision · time to disposition · loss avoided · customer action rate

The operating problem

Identity, payment, device and contact signals are each judged in the channel where they arrive. A pattern that is obvious in hindsight looks unremarkable event by event at the moment of decision, and the review that would have caught it is assembled by hand, after the exposure has been taken.

What the product produces

Prioritised, explainable cases for the first line, controls the customer can exercise in advance, and a record of disposition that the second line and internal audit can rely on without reconstructing it.

Capabilities

What it does, stated plainly.

Continuous monitoring of identity events: authentication, device and telecom changes, credential resets, and beneficiary additions
Explainable risk score from zero to one hundred, with each contributing signal named and weighted
Sequence detection, so changes clustered inside a short window are evaluated together rather than in isolation
Shared-attribute detection where a device or contact number links an implausible number of customer records
Beneficiary network analysis across accounts that receive value and pass it onward
Automated assembly of the escalated review file an analyst would otherwise compile by hand
Cross-context correlation across call transcript, message content, payment handle, and on-screen evidence
Recurring obligation discovery across cards, mandates, standing instructions, and merchant channels
Forward cash-flow position with a commitment score, plus mandate and dispute controls
Recommends but never executes; disposition authority remains with the institution
Consent-aware APIs, designed to operate alongside an incumbent fraud engine rather than displace it
Modules

Three modules, one model of evidence.

Each module addresses a different point in the customer relationship and can be deployed on its own. Run together, a signal raised by one can be read by the others.

01

Identity Guardian

Continuous identity risk monitoring

  • Maintains a chronological identity profile for each customer relationship
  • Escalates as sensitive changes cluster within a short window
  • Flags attributes shared across an implausible number of customer records
  • Delivers score, supporting evidence, network view, and a recommended disposition
02

ContextGuard

Payment context interception in real time

  • Correlates call transcript, message content, payment handle, and on-screen evidence
  • Weighs the instruction against the customer's own history and established beneficiaries
  • Links a beneficiary handle to previously reported cases and associated accounts
  • Warns the customer at the point of instruction, before confirmation
03

Control Tower

Recurring obligation visibility and control

  • Discovers subscriptions, instalments, and mandates across payment rails
  • Resolves the underlying merchant behind abbreviated and inconsistent descriptors
  • Forecasts upcoming obligations and the cash pressure they create
  • Places mandate and dispute controls directly with the customer
Demonstrated behaviour

Not one of these events is remarkable on its own.

Customers change telecom providers, reset credentials and register new devices as a matter of course. Identity Guardian scores the combination, and the interval between events, rather than any single one of them, and takes a clean relationship to a critical position across a realistic attack sequence.

StepEventScoreStatus
BaselineEstablished account behaviour
0
Good
01Telecom identifier changed
18
Good
02Credential reset
35
Good
03Authentication from a new device
50
Medium
04New beneficiary registered
76
High
05High-value transfer instructed
94
Critical

Output from the working prototype on synthetic data. It shows how the scoring behaves. It is not a performance claim against a live portfolio.

Why the demand exists

Operational intelligence with a clear purpose.

An institution can process every instruction correctly and still leave both the analyst and the customer without the context that would have changed the decision. Each module addresses that gap from a different side, and each rests on the same premise: the institution, not the model, holds the judgment.

Signals sit in separate channels
Identity, payment, device and contact events are each judged where they arrive, so the connection between them is never drawn.
Risk is a sequence, not an event
A SIM swap, a credential reset and a new payee are unremarkable alone and material together, inside a short window.
The persuasion happens off-system
A scam is built in a call, a message or a screen that the payment rail never sees, so the transfer itself looks entirely normal.
Escalated review does not scale
Accounts recruited to receive value and pass it onward are opened and discarded faster than a manual review queue can work through them.
Commitments surface too late
Recurring debits are scattered across rails and merchant descriptors, so the first clear signal is often the money leaving.
Product readiness

A working foundation. A clear path to deployment.

Explore the capabilities available to demonstrate today and the next milestones for a focused pilot. Together, we define the integrations, validation and deployment requirements for your operating environment.

Ready to demonstrate
  • Identity monitoring prototype demonstrated end to end, escalating a clean relationship to a critical score across a realistic attack sequence
  • Context correlation engine with an evidence graph and preset typology scenarios
  • Recurring obligation prototype grounded in real financial state, with forecasting and a commitment score
  • Explainable rules engines with centrally governed weights, supported by automated test coverage
Next steps for a pilot
  • Planned pilot milestone: connect authorised production data and the partner’s banking, telecom or bureau interfaces
  • Planned pilot preparation: implement production authentication, encryption and deployment infrastructure
  • Deterministic scoring today, with a model-based roadmap guided by transaction history and model-risk review
  • Pilot preparation: agree consent, retention and data-residency controls with the partner’s compliance team