When the transaction is legitimate but the customer isn't free.
PSR PS24/7 made affective evidence load-bearing for UK retail banks: when a customer claims they were scammed, the sending and receiving PSPs split liability 50/50 unless they can document that the customer authorized freely and with full understanding. RTP, FedNow, Pix, and SEPA Instant make the same truth real-time everywhere else. RTScale captures what your fraud stack can't: documented evidence that the customer authorized the payment with intact understanding and free of deception — at the moment they pressed send.
Seven minutes that decide who's liable.
Sarah, 67, authorizes a £14,200 Faster Payment to her "bank's fraud team." She'll realize it was a scam by lunchtime. Whether her PSP is on the hook for the £85,000-cap reimbursement depends on what gets documented during this window. Here's how RTScale's signal would fit into it, once a bank's integration is live end-to-end:
For Sarah
Plain-language explainer: what the bank saw, why the hold happened, what she can do if she disagrees. No deception accusation. No clinical claims. Respect for her authorship of the moment.
For the reviewer
Decomposed affect indicators with cohort-normalized baselines. Signature provenance and verification chain. PSR PS24/7 reasonable-grounds language ready to file. Audit trail to T+5 years.
Same signal. Different latency budgets.
RTScale captures the same affective signature across these flows. What differs is where it sits in your stack, what counts as a reasonable response, and which regulator is asking the question.
APP scam protection
The flagship case. Customer is conscious, biometrics match, device is theirs — but a coached caller is reading them a script. Reimbursement liability falls on the sending PSP unless free-authorization can be evidenced. Deep Scan during the standard friction screen captures the documented record.
Instant payment fraud
Once funds settle on an instant rail, recovery is functionally impossible. The fraud decision happens in the authorization window — typically <1 second end-to-end. Quick Scan inference fits inside that budget; Deep Scan reserves itself for step-up flows where the rail tolerates added friction.
High-value wire transfers
Business email compromise, vendor impersonation, social-engineered wires. These are not real-time decisions — the bank's existing wire approval workflow tolerates a 30-second Deep Scan and a senior banker call-back. Affect indicators are presented to the call-back banker; documented signature lives in the audit trail.
Card-not-present step-up
3DS challenges already happen at the moment of truth — they are the most concentrated authentication signal in card payments. RTScale's Quick Scan during the 3DS challenge attaches as an extension data field to the ACS response, letting the issuer's frictionless-vs-challenge decision become affect-aware.
In-branch teller alerts
A customer arrives with a companion to withdraw $20,000 in cash for "an investment." The teller's training says something's off; their SOP gives them no documented basis to act. The Desktop SDK captures from the teller-facing camera with consent, generates the same signature, and gives the branch manager documented grounds.
Built to slot in, not to replace.
The signature is a signal, not a decision engine. RTScale runs parallel to your existing identity, risk, and screening layers and delivers via webhook or queue into the platform you already trust. You decide policy. We add evidence.
A signal layer, not a decision layer.
RTScale doesn't compete with your fraud platform. The signed signature flows alongside the payment instruction into whatever decision engine you already run — Featurespace, Actimize, SAS, or your own ensemble.
Your policy decides what to do with affect indicators. Hold for reflection. Trigger step-up. Add to an ensemble score. Pass through with documentation. These are your choices, not ours.
Integration is REST + webhook for cloud-deployed banks; on-premises VPC peering and message-queue (Kafka, IBM MQ) handoffs for the rest.
What you can show a regulator on day one.
RTScale isn't a compliance shortcut — it's an evidence layer. Each major regulation has a specific question; the signature, paired with the right reporting template, answers it.
Frequently asked review questions.
Pulled from actual conversations with bank security, model risk, procurement, and DPO teams. If your reviewer asks something not here, ask us — we'll add it.
Yes to both. Affect data derived from facial and vocal capture is special-category personal data; payment-authorization use is Annex III high-risk under the EU AI Act. We provide a starter DPIA template and a FRIA template populated with our system characteristics. Cryptographic revocation materially reduces residual risk on an erasure request: the record becomes unverifiable to any relying party immediately, ahead of and independent from any procedural deletion timeline.
Parallel signal, not replacement decision engine. The signed signature flows into your existing fraud platform via webhook or message queue (REST, Kafka, IBM MQ) and joins your ensemble score — or sits as a side-channel attestation if you want to keep the existing ensemble untouched. Your policy decides what to do with the signal. Several of our design partners run RTScale alongside their incumbent platform as a co-equal signal in their hold/step-up logic.
A refusal is itself a documented event — captured under the Presence signature class with the customer's explicit choice signed and timestamped. Your bank's policy then decides whether a refusal triggers step-up review, manual processing, or proceeds with a documented decline-to-scan. We don't make that policy choice for you. We do recommend that refusal does not by itself trigger denial of service, both for fairness reasons and because some refusals may come from a customer who is being actively scammed in the moment.
Three structural commitments. First, the demographic-parity gap target on false-flag and escalation rates is ≤5 percentage points across race, gender, and age band, monitored against our evaluation corpus ahead of each release. Drift beyond target triggers retraining. Second, the system does not output a single "deception score" — it outputs decomposed indicators a reviewer can read. A trembling voice does not mean the customer isn't acting freely; the indicator surfaces facial-affect, prosodic, and gaze components separately so the reviewer can weight them. Third, individual baselines are established at session start (Quick Scan) so deviation is measured against the customer's own envelope, not a generic population mean.
Standardized eval pack, available under NDA: 500 labeled multimodal samples across cohorts; reproducible accuracy, fairness, and robustness metrics; SOC 2 Type II report; SBOM and dependency provenance; threat model and red-team summary; the Article 11 EU AI Act technical documentation set; signed signature reference vectors so your team can verify the cryptographic chain independently. We expect a typical bank's model-risk team to take three to five weeks with this pack before signing.
Signatures are signed by hardware-rooted keys (TPM 2.0, Apple Secure Enclave, Android StrongBox) with verifiable signature chains. Verification is offline-possible from the public key infrastructure — you do not need a live connection to RTScale to verify a signature five years out. The keys themselves are governed by your tenant; a specific customer's revocation request invalidates their keys, not the bank's infrastructure. Backwards-compatibility commitment is documented in the SLA: signatures signed today will be verifiable through 2036 at minimum, with a defined deprecation runway thereafter.
Quick Scan: ≤200 ms p95 on-device, measured across the device matrix in our published device-compatibility table. Deep Scan: 30 s, used only on threshold-crossing transactions where the rail tolerates added friction (APP scams, high-value wires, branch). The Quick Scan budget fits inside the RTP authorization window with room to spare; we'd be happy to walk through your specific rail's timing budget in the demo and show you the on-device benchmarks.
You do. Your policy. The whole point of an explainable, decomposed signature is that your fraud-strategy team can decide how to combine signals — additive, multiplicative, dominant-when-affect-confidence-is-high, or supplied-but-ignored-by-policy. Several of our design partners run the signature in passive mode for the first 60-90 days to calibrate their ensemble weights before letting it influence holds. We support that calibration period with shadow-mode reporting and disagreement analysis.
The demo uses the APP scam your reimbursement team is fighting right now.
Walk us through the case keeping your team up. Real claim, real customer profile (anonymized), real reimbursement exposure. We'll show capture, signature, adjudication, and both the customer-facing and reviewer-facing reports the moment would have produced. Thirty minutes. No deck.