Edge-Native Fraud Telemetry & Threat Intelligence Federation
Abstract
Modern financial ecosystems face an asymmetric threat: instant, automated bank fraud orchestrated through coordinated mule account networks. In Malaysia, where mobile-centric digital banking and e-wallet transfers (MAE, Setel, Touch 'n Go) dominate, the lag between a victim executing a transfer and the National Scam Response Centre (NSRC) or receiving bank blocklisting the mule account represents a multi-million dollar vulnerability. Furthermore, regulatory frameworks like the Personal Data Protection Act (PDPA) limit the sharing of threat intelligence due to risks of exposing victim or bystander Personal Identifiable Information (PII).
Waspada AI resolves this structural vulnerability by introducing edge-native destination-account intake from victim evidence — not in-session behavioral biometrics. By parsing transaction receipts and chat logs on-device inside the host banking application (or public sandbox), Waspada extracts core threat indicators (mule account numbers, bank BIC codes, scammer aliases, and malicious URLs), strips PII (NRIC, phone, email), and cryptographically uploads the metadata to an Orchestration Gateway. The Gateway signs advisory FMS alert JSON for bank webhooks and formats STIX 2.1 for analyst export / offline samples (not a live SIEM push), supporting RMiT-aligned threat-sharing discussions — not BNM certification. Demand driver for banks: RMiT Appendix 11(2)(b)(viii); packaging characterisation: Outsourcing PD Appendix 2(n)/(o) (counsel TBD) — we are not the national mule repository.
1. Introduction & The Mule Problem
Mule accounts are the lifeblood of digital fraud. Once a scammer tricks a victim, funds are routed through multiple layers of compromise within seconds. Current defense frameworks are bottlenecked by:
- High Reporting Latency: Victims report to customer service or the police hours after the incident. By then, the mule account has been drained.
- Privacy (PDPA) Compliance Hurdles: Sharing raw transaction receipts across bank firewalls exposes sender names, balances, and NRIC (national ID) numbers.
- Integration Overhead: Traditional Security Information and Event Management (SIEM) systems lack specialised parsers for Malaysian banking formats.
Waspada AI bypasses these hurdles by pushing the intelligence extraction to the edge (the mobile client) and standardising the egress metadata using the Structured Threat Information Expression (STIX 2.1) global format.
2. Architecture Overview
Waspada AI is organised into a modular architecture spanning three layers: the client-side Edge SDK, a centralised Orchestration Gateway, and downstream integrations with bank risk engines and SOC platforms.
2.1. Client-Side Edge Extraction (Three-Tier)
The Edge SDK implements a multi-tier extraction pipeline that runs entirely on the client device. No receipt image, PDF, or raw OCR text is uploaded to Waspada servers.
- Tier 1 — Regex / pattern matching: Deterministic extraction of Malaysian bank account numbers, SWIFT/BIC codes, URLs, and structured aliases. Typically under 10 ms on mobile hardware. Source of truth for hard fields.
- Tier 2 — NER encoder: On-device named-entity recognition (DistilBERT-class) fills gaps on informal aliases and bank-name mentions when regex is incomplete.
- Tier 3 — SLM assist: A small on-device language layer normalises ambiguous fields and can draft a Bahasa Melayu ringkasan for victim-facing draft police reports. Same interface across hosts; backend is selected by runtime:
- Partner native app (iOS): Prefer Apple on-device Intelligence / Foundation Models when available.
- Partner native app (Android): Prefer the device’s on-device system AI when available.
- Web / PWA / public triage: Waspada’s own web SLM path (Phase A structured preview today; quantized generative weights on the roadmap).
- Fallback: If platform AI is unavailable, degrade to web SLM → NER → regex. Extraction never hard-fails because a model is missing.
2.2. Receipt & Image Processing
- Digital Receipts: Embedded text is extracted directly from PDF documents using WASM-based parsing, avoiding server-side upload entirely. Built-in safeguards prevent decompression-bomb attacks on oversized documents.
- Scanned Receipts & Screenshots: Image-based receipts are processed through an on-device OCR pipeline with pre-processing steps (binarisation, noise reduction) optimised for variable lighting conditions common in screenshots shared via messaging apps.
2.3. Public Triage Path (Citizens & NGOs)
Alongside in-app bank embedding, Waspada operates a public digital defense front door:
- Interactive sandbox (live at /sandbox/): zero-account public triage with client-side draft police report PDF generation. Does not write into the bank FMS path.
- WhatsApp (closed public ingest — ADV-005): an optional wa.me link may still open the sandbox URL in chat. Quarantine writers are not live; WhatsApp is not a citizen→bank door and must not be used to send receipt media.
Banks buy the intelligence feed; citizens and community responders use free sandbox triage. CSR sponsorship can fund public hosting without replacing FMS procurement.
Privacy-by-Design: Receipt images are not uploaded for Waspada cloud inference. NRIC, phone, and email are stripped on-device and re-checked at the gateway. Only extracted, PII-stripped threat indicators are transmitted. Scammer aliases may egress under configurable policy (hash / include / omit). Absolute “zero PII egress” is not claimed.
3. Security Model & RMiT Alignment
Deploying within Bank Negara Malaysia's (BNM) Risk Management in Technology (RMiT) framework requires strict security properties. Waspada's security model addresses three critical areas. This is a paragraph-cited mapping — not BNM certification.
3.1. Non-Repudiation & Replay Protection
Telemetry payloads must not be replayable by third parties. Waspada implements a multi-layer authentication and integrity scheme:
- Asymmetric Signing: Each partner banking application signs telemetry using its own private key (RS256). The gateway verifies using the corresponding public key, ensuring payload authenticity.
- Unique Token Identifiers: Every telemetry payload includes a unique, time-bounded token. The gateway maintains a short-lived cache to detect and reject duplicate submissions.
- Expiration Enforcement: Tokens are validated against strict expiration windows. Stale payloads are rejected regardless of signature validity.
Note: Implementation details of the replay protection mechanism, key rotation schedules, and cache eviction strategies are available under NDA to pilot partners.
3.2. Privacy Controls (PII Scrubbing)
Before any metadata leaves the client device, it passes through a PII scrubbing filter calibrated for Malaysian formats. Detectors strip:
- National Registration Identity Card (NRIC) numbers
- Malaysian mobile phone numbers (carrier prefixes)
- Email addresses
The structured telemetry schema does not select victim names or account balances for egress. Scammer aliases may egress under configurable policy (hash / include / omit). Absolute “zero PII egress” is not claimed.
The gateway implements a secondary PII firewall that re-scans incoming payloads for NRIC / phone / email. Any payload that fails the secondary check is rejected — defense-in-depth against SDK tampering.
4. Federated Interoperability (STIX 2.1)
The Orchestration Gateway formats validated telemetry into Structured Threat Information Expression (STIX) 2.1 objects for analyst export and offline sample use. Live bank delivery today is the signed FMS JSON webhook — not an automated SIEM push. STIX formatting is gated in CI (suppress patterned indicators while advisory).
Example output (sanitised):
{
"type": "bundle",
"id": "bundle--[generated-uuid]",
"objects": [
{
"type": "indicator",
"pattern": "[bank-account:account_number = '[REDACTED]'
AND bank-account:bic = '[BANK_BIC]']",
"pattern_type": "stix",
"valid_from": "2026-07-09T09:00:00Z",
"indicator_types": ["malicious-activity"]
}
]
}
Analyst SSE streams the signed FMS alert JSON (ticket-authenticated). STIX 2.1 is produced by the gateway formatter for export / offline sample use — not a live SIEM push in the current runtime. While disposition is advisory, patterned auto-actionable indicator SDOs are suppressed.
5. Deployment Model
Waspada is designed for flexible deployment:
- Edge SDK (in-app): Lightweight package for partner mobile banking / e-wallet apps (React Native, native iOS/Android). When embedded natively, Tier 3 prefers Apple or Android on-device AI; otherwise the web SLM path applies.
- Public triage: Browser sandbox for citizens and NGO responders — web SLM only, PII-stripped before any partner transmission. Public reports do not write into the bank FMS path — the ingest door is closed (ADV-005 quarantine writers are specified, not live). WhatsApp is not a live public ingest channel.
- Orchestration Gateway: Managed or self-hosted. Verifies partner JWTs, re-checks PII, enriches domains, streams FMS alerts. HTTPS/TLS 1.3 only.
- Analyst Console: Same-origin portal at
/analyst/for SOC analysts — ticket-authenticated SSE, STIX export, acknowledge workflows.
6. Trust & Security
We publish our own threat model, red-team audit residuals, and compliance mappings. Review the evidence, not the marketing.
Security Posture
CISO Resources
7. Conclusion
Waspada AI bridges the critical latency gap in fraud detection while strictly respecting personal data privacy laws. By executing parsing and redaction on the customer's device, partner banks can receive advisory mule-indicator feeds far faster than hotline queues — without automating freezes. Standardizing this data flow with STIX 2.1 helps the financial sector share structured threat intelligence.
The platform is currently in pilot stage, designed for integration with forward-thinking Malaysian banks, regulatory bodies, and anti-fraud teams. Full technical documentation, architecture deep-dives, and security audit reports are available to pilot partners under mutual NDA.