Skip to content

AI for Banking

The fraud that hurts looks exactly like a real transaction.

We engineer AI for retail and commercial banks: real-time fraud scoring with reasons a case worker can read, KYC and CDD in minutes, transaction monitoring that triages its own alerts, and dispute workflows that close with evidence.

Built to your core, your card network, and the oversight your regulators already expect.

Discuss your fraud and onboarding workflowSee how the system works

The operational reality

Fraud looks normal. KYC takes days. Branches queue.

The expensive loss is the transaction that cleared. The expensive customer is the one who signed up next door.

Rules catch the obvious. The money moves on the rest.

Felt by heads of fraud operations, chief risk and compliance officers, heads of digital, and the case workers and KYC analysts who absorb what weak scoring leaves behind.

  1. 01

    Intake and screening

    A customer attempts a transaction or opens an account across a channel: card present, card not present, ACH, wire, mobile, or branch. Device, geo, counterparty, and identity signals land in milliseconds.

    Friction · Signals arrive from different systems at different latencies; the screening layer sees only part of the picture.

  2. 02

    KYC and sanctions screening

    New customers are run against identity, document, and sanctions providers. Beneficial owners are collected on commercial accounts. OFAC and PEP lists are matched.

    Friction · KYC backlogs stretch into days; applicants drop out and open an account at a neobank instead.

  3. 03

    Decisioning

    A score is produced on the transaction or application. Rules fire on hard criteria such as sanctions and velocity. A model layer scores softer patterns.

    Friction · Rules alone over-decline on busy days; models alone cannot explain themselves to a case worker.

  4. 04

    Exception handling and case work

    Flagged items drop into a case-management queue. A fraud or AML analyst reviews the signals, pulls the customer history, and decides to approve, hold, step up authentication, or escalate.

    Friction · Queues outpace analysts; the oldest cases get worse the longer they sit.

  5. 05

    Resolution and reporting

    A decision is executed on the network or core, a letter or notice is sent, and the case is logged. SARs are filed where thresholds are met, chargebacks are responded to, and the audit trail is sealed.

    Friction · Evidence for a chargeback is reassembled by hand from screenshots and logs; narratives for SARs are rewritten each time.

Swipe the workflow

Where the work breaks

The friction is in the places nobody budgets for.

  • 01

    Rules-only engines over-decline on real customers at the worst moments.

    How we fix it · A system we build catches this before it costs you.

    Impact · Checkout abandonment, support calls at the branch, and a customer who moves their primary account to a competitor the same week.

  • 02

    KYC onboarding stretches into days because document and screening steps run end to end instead of in parallel.

    How we fix it · A system we build catches this before it costs you.

    Impact · Applicants drop out before funding. Acquisition spend lands in a neobank that approved them in minutes.

  • 03

    AML alerts land in a queue with no triage: equally scored, equally timed, equally urgent.

    How we fix it · A system we build catches this before it costs you.

    Impact · Analysts work the top of the list regardless of risk; genuinely suspicious activity ages while routine alerts are cleared.

  • 04

    Dispute and chargeback packets are rebuilt by hand from screenshots, logs, and merchant portals.

    How we fix it · A system we build catches this before it costs you.

    Impact · Representment deadlines are missed, winnable chargebacks are abandoned, and recovery drops.

  • 05

    Case workers cannot see why a model scored a transaction the way it did.

    How we fix it · A system we build catches this before it costs you.

    Impact · They override the model on gut feel, model performance drifts, and the governance team has nothing to show the regulator.

What we would build

Systems, not features. Each with its own job.

  • 01

    Real-time fraud scoring with explainability

    Rules engines miss the subtle cases and over-decline the real ones; a black-box model is a non-starter for the risk committee.

    Who benefits · Fraud operations, card operations, digital banking, and the case workers who review alerts.

    Inputs
    The transaction event stream, the customer history on the core, device and session signals from the channel, counterparty and merchant features, and the bank own labelled fraud outcomes.
    What the system does
    A sub-100ms model layer scores every transaction and emits the top contributing features by weight. Deterministic rules remain in front for sanctions and hard-stop conditions. Decisions, scores, and feature attributions are logged on every event.
    Output
    An approve, hold, or step-up decision on each transaction, with a short set of reason codes a case worker can read.
    Benefit
    Fewer good customers declined, more subtle fraud caught, and a model file the risk team can take through SR 11-7 review.
    Human stays here
    The model never acts alone on anything irreversible. Low-confidence calls route to a case worker; thresholds and override authority sit with the fraud operations team.
  • 02

    KYC and CDD acceleration

    Onboarding runs serially across identity, document, screening, and beneficial-ownership steps; applicants drop out before any decision is made.

    Who benefits · KYC analysts, onboarding operations, compliance officers, and the digital team that owns funnel conversion.

    Inputs
    The applicant form, the identity and document provider responses, OFAC and PEP lists, UBO structures on commercial accounts, and the bank own risk policy.
    What the system does
    Independent checks run in parallel. The system assembles a case file with each check scored and timestamped, matches sanctions and PEP hits with fuzzy and transliteration-aware matching, and drafts the analyst decision narrative with every claim linked to the source document.
    Output
    A case file ready for a KYC analyst to approve, step up, or decline, with the narrative pre-drafted and every risk factor cited.
    Benefit
    Onboarding moves from days to minutes on the clean cases, so acquisition spend lands in a funded account instead of a drop-off.
    Human stays here
    Every decline, every elevated-risk approval, and every sanctions hit is reviewed by a named analyst. The system never approves a high-risk case on its own.
  • 03

    AML transaction monitoring and case triage

    Scenario rules fire on everything equally. Analysts spend their day clearing low-value alerts while the real ones age at the bottom of the queue.

    Who benefits · AML analysts, financial-crime investigators, and the BSA officer.

    Inputs
    The transaction history, counterparty graph, sanctions and PEP signals, prior SAR filings, and the scenarios the bank already runs.
    What the system does
    Scenario alerts remain in place for deterministic coverage. A supervised scoring layer learns from the bank own disposition history to rank alerts by investigator priority, cluster related alerts into cases, and draft the SAR narrative with linked evidence when the threshold is reached.
    Output
    A ranked queue, pre-clustered cases with their evidence attached, and SAR narrative drafts for the BSA officer to review and sign.
    Benefit
    Analyst time moves to the cases that matter. Investigation cycle time falls without reducing coverage.
    Human stays here
    No alert is auto-cleared. Clustering and ranking are shown with the signals behind them so analysts can override. Every SAR is filed by a named human.
  • 04

    Dispute and chargeback automation

    Representment packets are reassembled by hand against short network deadlines. Winnable disputes are abandoned because the evidence is scattered across the merchant portal, the authorisation log, and the customer record.

    Who benefits · Dispute operations, chargeback analysts, and card operations.

    Inputs
    The authorisation and settlement records, the merchant category and reason code, the customer transaction history, delivery and 3DS evidence from the acquirer, and the network dispute rules.
    What the system does
    The system pulls every piece of evidence tied to the disputed transaction, maps it to the network reason code, and drafts the representment packet to the issuer or acquirer specification. Deadlines are tracked per case.
    Output
    A completed representment packet, labelled by win-probability band, ready for a chargeback analyst to review and submit.
    Benefit
    More winnable chargebacks are actually represented. Recovery rises without adding headcount.
    Human stays here
    A chargeback analyst approves every packet before submission. The system flags cases where the evidence does not support a representment rather than filing a losing one.
  • 05

    Contact-center knowledge agents

    Branch and contact-center agents re-ask the same questions and dig through policy PDFs while the customer waits. Phone queues bottleneck the moment anything out of the ordinary happens.

    Who benefits · Contact-center agents, branch staff, and the customer digital self-service experience.

    Inputs
    The bank own policy library, product terms, procedure manuals, the customer transaction history where consented, and the digital banking entitlements.
    What the system does
    A retrieval system indexes bank policies and procedures with hard tenant boundaries. Agents and customers ask natural-language questions and receive answers with the exact policy passage cited. Complex calls route to a human with the context already summarised.
    Output
    Grounded answers for agents and customers, warm handoffs with a pre-drafted summary, and a disclosure that the responder is an assistant.
    Benefit
    Call handle time drops. Agents spend their day on the calls where a human voice matters, not on policy lookups.
    Human stays here
    Anything resembling account action still routes to an authenticated agent. The assistant declines to answer rather than guess when retrieval confidence is low.

Show the system

What it could look like in your hands.

A design concept, not a shipped product. Interfaces like this get drawn out before any code lands, so the system reads back the way the people using it work.

fraud ops / case review

Flagged queue

  • TX-80421 · 14:02:11 UTC

    USD 2,480.00

    Electronics retailer, SF

    Card not present

    92 / 100
    • velocity
    • device-new
    • geo-mismatch

  • TX-80422 · 14:01:58 UTC

    USD 189.44

    Fuel merchant, Dallas

    Card present

    71 / 100
    • mcc-high-risk
    • amount-outlier

  • TX-80423 · 14:01:40 UTC

    USD 12,500.00

    ACH to external bank

    Online banking

    88 / 100
    • ato-pattern
    • device-new
    • velocity

  • TX-80424 · 14:01:22 UTC

    USD 65.20

    Streaming service

    Card not present

    46 / 100
    • bin-mismatch

  • TX-80425 · 14:00:49 UTC

    USD 4,900.00

    Wire, cross-border

    Branch

    83 / 100
    • counterparty-new
    • sanctions-near-match

USD 2,480.00

TX-80421 · Card ending 4418 · Customer 90421 (synthetic)

Electronics retailer, SF

Card not present · 14:02:11 UTC

Model confidence

86%score 92 / 100
Decision: Hold for step-upfraud-cnp-v4.2

Top contributing features

  • Transactions in last 10 minutesw 0.34

    4 on this card

  • Device first seen todayw 0.28

    Yes, Chrome on Android

  • Billing to shipping distancew 0.19

    1,920 miles

Session history

  1. 14:00:02Login from new device, Chrome on Android
  2. 14:01:12Shipping address added, differs from billing
  3. 14:01:58First attempt at USD 2,480 declined by 3DS
  4. 14:02:11Retry at USD 2,480 cleared 3DS, scored by model
Synthetic data. This is a design concept of how a flagged queue, a focused case with model confidence and top contributing features, and an audited action pane could look in a case worker hands.

End-to-end workflow

From the trigger to the outcome.

A representative path for a flagged transaction, from the moment the event lands on the bus to the moment the case is sealed. Automated stages run inside the latency budget; human stages are explicit, named, and never skipped.

  1. 01

    Trigger

    A payment or application event lands on the real-time bus with device, channel, counterparty, and identity signals attached.

    Automated
  2. 02

    Score

    The model scores the event in under 100ms, emits a decision band, and surfaces the top contributing features by weight. Deterministic rules fire alongside for sanctions and hard-stop conditions.

    Automated
  3. 03

    Low-confidence refusal

    When model confidence is below threshold, the system does not auto-decide. It raises a case to a named analyst with the signals and the model confidence surfaced.

    Guardrail
  4. 04

    Challenge

    If the band warrants it, a step-up challenge is issued through 3DS, push, or SMS. The outcome of the challenge updates the case.

    Automated
  5. 05

    Case worker review

    A fraud or AML analyst reviews the case in a console: queue context, customer history, model confidence, reason codes, and the top features. The analyst approves, holds, steps up, or escalates.

    Human in loop
  6. 06

    Decision

    The decision is attributed to a named analyst or to a policy. It is logged with the model version, inputs, and timestamp.

    Automated
  7. 07

    Card network callback

    The decision is returned to the card network or the core on the required interface so authorisation can resolve inside the switch timeout.

    Integration
  8. 08

    Act

    On approve, authorisation clears. On hold or decline, the customer receives a notice. On case open, the item routes to AML or dispute operations with its evidence attached.

    Integration
  9. 09

    Log and audit

    The full case file is sealed to the audit store: inputs, model version, decision, reviewer, outcome, and any SAR or Reg E notice triggered.

    Automated

How exceptions are handled

  • If the feature store cannot be reached inside the latency budget, the system falls back to deterministic rules and flags the item for review rather than guessing.
  • If a sanctions screening provider is slow or returns an error, the transaction is held rather than cleared through the fast path.
  • If a case worker is not available inside the time window the card network allows, the system defaults to the conservative decision and opens a case for post-decision review.
  • If the model confidence is below threshold, the system refuses to decide and routes the case to a named analyst.
  • If a customer revokes consent to a channel signal, derived scores built from that signal are purged on the next model run.

How it is engineered

Built on your stack, not ours.

Design choices that let this run inside a core banking authorisation window, not inside a demo. We build to your card switch, your core, your KYC providers, and your model-risk governance, not to our stack.

01

Real-time event bus and feature store

A streaming layer carries payment and session events. A feature store holds pre-computed signals at the latencies they are actually needed, so the model does not re-derive them in the critical path.

02

Model serving under 100ms

Fraud and risk models are served on a tight latency budget with a hot cache for feature lookups. Models are versioned, A and B deployable, and shadow-able against the live decision stream before any traffic shifts.

03

Explainability layer

Every scored event emits the top contributing features by weight. Case workers see what the model saw; the model risk team gets attribution they can take through SR 11-7 review.

04

Policy and rules engine

Deterministic rules sit in front for sanctions, velocity caps, hard-stop channels, and jurisdictional conditions. Rules are versioned, approvable, and separately logged.

05

Case management and regulator-facing audit trail

Flagged items land in a case store with the full inputs, model version, reasons, and reviewer attribution. The audit trail is append-only and sealed to the retention policy your examiner expects.

06

Observability and model monitoring

Live monitoring on model drift, population stability, false-positive rate at a fixed capture threshold, and challenger-model performance. Degradation triggers an alert before it reaches a customer.

What the business will measure

Numbers the operator already watches.

We agree on metrics and baselines before building. These are the numbers a fraud, AML, or risk operations leader usually watches when deciding whether a system is working.

  • 01

    Fraud loss in basis points of authorised volume

    Baseline today

    Current gross fraud loss, by product and channel, as a share of authorised volume over the trailing twelve months.

    How it moves

    Model scoring catches patterns rules miss; case triage puts analyst time where it earns the most. Loss falls without the decline rate climbing.

  • 02

    False-positive rate at a fixed capture threshold

    Baseline today

    Current ratio of good transactions declined to fraudulent transactions caught, measured at today operating threshold.

    How it moves

    A model layer with explainability lets the operations team tune the threshold with the risk committee, holding capture while cutting the good-customer declines.

  • 03

    KYC onboarding time, median and 90th percentile

    Baseline today

    Current time from application submitted to decision rendered, by product and segment.

    How it moves

    Independent checks run in parallel instead of in series; analyst review lands with the narrative drafted and the evidence linked.

  • 04

    AML case backlog and investigation cycle time

    Baseline today

    Current queue depth, median time to disposition, and oldest open case age across the AML team.

    How it moves

    Ranking and clustering focus analyst time; narrative drafts cut rework. The queue stops aging into risk.

  • 05

    Dispute and chargeback cycle time and win rate

    Baseline today

    Current average time from dispute received to resolution, and win rate on represented chargebacks by reason code.

    How it moves

    Evidence is assembled and mapped to the network reason code at intake; analysts spend their time on the cases that are winnable.

Human in the loop

Oversight, safety, and the data boundary

Where the humans stay in control.

The system is designed around the governance and consumer protections a US or EU bank already operates under. Nothing is autonomous that should not be.

  • 01

    Model risk management (SR 11-7, OCC 2011-12)

    Every model ships with a model-risk file: intended use, data lineage, performance by segment, limitations, challenger comparisons, and the monitoring plan. Independent model validation is supported, not fought.

  • 02

    Consumer protections (Reg E, Reg Z, Reg B)

    Decisions that fall under Reg E, Reg Z, or Reg B are routed through the right notice workflow: provisional credit timing, adverse-action reasons, and the disclosures each regulation requires are templated and auditable.

  • 03

    Explainability and adverse-action notice

    Every model decision carries the top contributing features. For decisions that trigger an adverse-action notice, those features drive the reason codes delivered to the customer in plain English.

  • 04

    Data residency and tenancy

    Customer and payment data stays in the region the bank specifies. The system runs in the bank own cloud tenant or in a dedicated environment operated for the bank. Cross-border movement is explicit, not implicit.

  • 05

    SOC 2 and PCI DSS scope

    The system is designed to sit inside the bank existing SOC 2 and PCI DSS boundaries. Cardholder data touches only the components that must; everything else sees tokens or synthetic references.

  • 06

    No training on customer data

    Base models are not trained on the bank data. Any fine-tuning happens inside the bank tenant, on the bank data, with the bank approval, under a model-risk file the bank owns.

Proof

Work we have shipped, and the shape of what we build.

Real engagements where we can speak to them, and representative use cases where we cannot.

How the build runs

Scoped tightly, shipped in phases.

Fixed price per phase, approved before the phase starts. You own the code, the models, the feature store, and the deployment.

  1. 01

    Discovery

    Two to three weeks. We sit with fraud operations, AML, and the risk committee, map the real workflow against your core and card switch, and agree on the metrics and baselines the system will move.

  2. 02

    Prototype on real data

    Six to eight weeks. One product line, one channel, one proof of mechanism in shadow mode against live traffic. Scores are logged alongside the production decision; nothing customer-facing changes yet.

  3. 03

    Model risk review and validation

    Runs in parallel with build. Model-risk file, independent validation support, challenger-model setup, and the monitoring plan are prepared for your model risk committee.

  4. 04

    Production rollout

    Eight to sixteen weeks per product line. Feature store, model serving, rules engine, case console, and the audit trail go live inside your tenancy. SSO, PCI scope, SOC 2 controls, and regulator-facing logs are signed off before traffic shifts.

  5. 05

    Handover

    You receive the full source, model artefacts, feature definitions, runbooks, and the evaluation suite. A two-week walkthrough with your engineering, model risk, and operations teams closes the engagement.

Common questions

Answers before the first call.

01How do you handle model risk management under SR 11-7 or EU equivalents?
Every model we ship comes with its model-risk file: intended use, data lineage, performance by segment, known limitations, challenger comparisons, and the monitoring plan. We support independent model validation rather than resist it, and we design around whatever your model risk committee and your OCC or regulatory examiner already expect. In the EU we build to the EBA guidelines and treat fraud and credit models as high-risk under the EU AI Act.
02Where do PII and payment data live, and what touches cardholder data?
Customer and payment data stays in the region your policy specifies, inside your own cloud tenant or a dedicated environment we operate for you under contract. Cardholder data touches only the components that must; everything else sees tokens or synthetic references, so we keep the PCI DSS boundary tight. Base models are never trained on your data, and any fine-tuning happens inside your tenant on your data with your approval.
03How fast are the decisions, and what happens if the model is slow?
Fraud scoring sits inside the authorisation window the card switch allows, usually under 100 milliseconds including feature lookup. If the model serving layer or feature store cannot respond inside the budget, deterministic rules take the call and the item is flagged for review. We do not guess to beat a timeout.
04What happens on model drift, and who notices first?
A challenger model runs alongside production and is scored on the same stream. Population stability, false-positive rate at a fixed capture threshold, and segment-level performance are monitored continuously. A drift breach alerts the model risk team and pulls the model from production into review before customers feel it. Your team sees drift before your examiner does.
05Who owns the models we build with you?
You do. You receive the source, the training pipeline, the feature definitions, the model artefacts, the evaluation suite, and the runbooks. We do not retain a licence, we do not require an ongoing retainer, and we do not use your data to train anything we sell to anyone else.
See the other details on the FAQ page

Next step

A thirty-minute conversation. Bring one product line where fraud loss or onboarding time hurts most today, and we will walk through what the first phase would look like, where the measurements come from, and what has to be true for your risk committee to approve it.

Discuss your fraud and onboarding workflow

Helpful to have on the call

Helpful to have on the call: current fraud loss in basis points by product, current false-positive baseline at today operating threshold, and current KYC and prior-authorisation turnaround times for the segment that hurts most.

Explore

A different problem in every sector, one engineering standard underneath.

Featured · AI for healthcare

Healthcare

Why is your clinician still charting at midnight?

Your clinicians are charting until midnight and your front desk is drowning in prior auths. We build AI that writes clinical notes automatically, triages patients to the right care faster, and finds any record with a simple question, so your people spend their hours on patients instead of paperwork.

See AI for healthcare
stallwart / healthcare

Live run

Healthcare

Running
as of nowhealthy
See every industry we build for

An AI-First Engineering Company

Get a price in one call.

One 30-minute call. You leave with an architecture, a fixed price, and a start date. No charge, and no slide deck.

Booking now for December 2026

Book a callSee how it works