Conventional FDS
Post-transaction reporting
- Transaction enters the switch
- Switch forwards to core banking — funds move
- FDS analyses the transaction afterwards
- Analyst opens a case — chases recovery
Fraud already happened.
Fraud Detection System
Block fraud before the transaction completes.
Fraud detection software for Indonesian banks, installed in your own data centre. It approves or blocks every transaction in real time — before it reaches core banking.
A product of PT Matajari Mitra Solusi
The problem
Fraud in digital banking now moves faster than conventional safeguards.
- Scale
Transaction volume keeps climbing
BI-FAST, QRIS, mobile banking and card rails grow at double-digit rates every year. Fraud attempts grow at the same pace — and industrial-scale syndicates adapt faster than any rule-review cycle.
- Cost
Losses stack on every side
Direct losses, customer reimbursement, investigation cost, brand damage, regulatory penalties — every incident lands on multiple lines at once.
- Regulation
Regulator expectations keep getting sharper
POJK 11/2022 mandates operational resilience. POJK 38/2016 mandates active risk management. Bank Indonesia expects real-time payment fraud controls.
Most installed fraud systems were wired to report, not block — they sit outside the transaction path and see funds only after they move. The challenge now is detection fast enough to block, before the transaction completes.
Conventional FDS reports fraud. Guardian blocks it.
Guardian
Synchronous authorization hook
- Transaction enters the switch
- Switch calls Guardian inline
- Decision in under 200 ms — approve or block
- Blocked transactions never reach core
Fraud never completes.
Three pillars — what makes Guardian different.
- 01
Real-time blocker
A synchronous block in under 200 ms on every write path to core. The switch — and every other rail — gets a verdict before funds move.
- Fifteen explainable rule types, dry-runnable per tenant
- Audit-ready decisions with the rule and evidence attached
- Fail-safe policy configured per bank (fail-open or fail-closed)
The spine of the product
- 02
Agentic AI co-pilot
Analysts describe fraud patterns in plain language. The agent proposes rules, explains why a transaction was blocked and suggests dispositions — a tool for the analyst, not a replacement.
- Rule-authoring co-pilot: plain language → rule parameters
- Case investigator: explains the reasoning, proposes a disposition
- On-premise LLM — no third-party API, no data leaves the bank
The differentiator
- 03
Bank-controlled ML
A supervised classifier that learns from your analysts’ dispositions. The bank controls the rollout — ML never blocks without explicit opt-in and months of shadow evidence.
- Shadow → advisory → enforcing, toggled per tenant
- Graph-based mule-ring detection and per-account velocity baselines
- Feedback loop: analyst dispositions become training labels
The learned signal
Synchronous authorization, in front of every path to core banking.
Channels
- ATM
- EDC
- BI-FAST
- Mobile
- QRIS · SKNBI · …
Bank switch Way4 or similar Standard auth protocol
sync
Rails that bypass the switch
- Mobile GWBanking app
- Open APISNAP · partners
- BranchIn-branch ops
- OtherBank-specific
direct
Guardian FDS
Rules + Agent + ML
Decision < 200 ms
Approve · block · timeout-safe
approved
Core banking Unchanged
Post-decision event stream → dashboard · audit · analytics
Channels
- ATM
- EDC
- BI-FAST
- Mobile
- QRIS · SKNBI · …
Bank switch Way4 or similar
Rails that bypass the switch
- Mobile GWBanking app
- Open APISNAP · partners
- BranchIn-branch ops
- OtherBank-specific
sync
Guardian FDS
Rules + Agent + MLDecision < 200 ms
Approve · block · timeout-safe
approved
Core banking Unchanged
Post-decision event stream → dashboard · audit · analytics
Guardian sits in front of core banking, not behind the switch. Card rails reach Guardian through the switch as before — no change to your switch integration. Rails that bypass the switch — mobile app, open banking, branch operations, anything bank-specific — plug in directly. Every write path to core flows through one synchronous blocking layer, while a separate event stream feeds the dashboard, audit log and analytics off the hot path.
What it catches
Fifteen rule types — every decision is explainable.
-
Transaction Amount
Thresholds per channel, per tenant, per segment — absolute and relative to a customer’s historical pattern.
-
Round Amount Anomaly
Round-figure transfers (IDR 5,000,000 / 10,000,000) outside the customer’s normal spending pattern.
-
Cumulative Amount
Aggregated transactions inside a time window crossing a limit, even when each individual transaction is small.
-
Transaction Velocity
Sliding-window count and sum across any dimension — card, account, beneficiary, device.
-
Transaction Time
Time-of-day, day-of-week and calendar anomalies, profiled per customer and per segment.
-
Rapid Sequence
Bursts of transactions seconds after a fresh login or a new enrollment.
-
Geographic Anomaly
Distance, country, region and impossible-travel checks against the customer’s location pattern.
-
High-Risk Country
Transactions to or from sanctioned, high-AML-risk or known-fraud-pattern jurisdictions.
-
High-Risk Merchant Category
Merchant categories tied to high-fraud activity — crypto, gaming, forex and the like.
-
Authentication Strength
Sensitive transactions completed with weak authentication (PIN only, no 2FA, no biometric).
-
New Beneficiary
Transfers to recently added beneficiaries — the common shape of OTP scams and social engineering.
-
Declined Retry
Rapid retry after a declined transaction — typical of stolen-card use or credential testing.
-
Cross-Device Account Usage
One device used by many different accounts — mule rings or credential stuffing.
-
Cross-Account Device Usage
One account accessed from many fresh devices in a short window.
-
Negative List
Blacklist of accounts, devices, IPs, beneficiaries and merchants — per tenant and from shared intelligence.
Every rule is configurable per tenant, dry-runnable against historical transactions, and explainable line by line. The agent co-pilot makes rule authoring conversational; ML scoring adds a learned signal on top.
Agentic AI — an analyst’s co‑pilot, not a replacement.
Describe a fraud pattern in plain language and the agent proposes a rule. Open a blocked case and the agent explains the verdict and suggests a disposition. Your team stays in charge — the agent surfaces options, the human decides.
Capability 01
Rule-authoring co-pilot
Analyst
“Block QRIS transfers above IDR 10 million, and block BI-FAST transfers above IDR 50 million to new beneficiaries.”
Guardian agent Proposed: Transaction Amount rule with per-channel overrides — QRIS 10M, BI-FAST 50M — scoped to new-beneficiary events. Dry-ran against the last 30 days: 42 matches, 3 historical false positives.
Outcome
The analyst reviews the proposed rule in the form builder, accepts or adjusts it, and deploys. The audit trail captures the prompt, the proposal and the reviewer.
Capability 02
Case investigator
Analyst
“Explain this blocked transaction. Is it fraud or a false positive?”
Guardian agent Transaction IDR 47.5M to a beneficiary added 8 minutes earlier, from a device first seen today. Two rules fired: New Beneficiary + Rapid Sequence. Matches the pattern of 14 prior confirmed-fraud cases on this tenant. Recommendation: mark as fraud; notify the customer.
Outcome
The analyst dispositions the case in one click. The disposition feeds the ML training loop — the system learns from every decision.
Runs on a local LLM inside your network (Ollama, Qwen 2.5). No third-party API, no data leaving the bank. A cloud-API mode is available per tenant for iteration and benchmarking — never for production traffic by default.
ML that earns its way to the hot path.
Rollout ladder — controlled by the bank
- Stage 01 Shadow
Scores computed off the hot path. No influence on decisions. Evidence accumulates.
- Stage 02 Advisory
Scores surface on the dashboard and as an optional rule — the bank opts in per rule, at no latency cost.
- Stage 03 Enforcing
A hot-path blocking rule. Requires months of shadow evidence, explicit opt-in and a runbook.
The bank owns the progression. ML never blocks without explicit tenant-level opt-in and months of shadow-mode evidence — a posture built for the regulator conversation.
Feature stack
- Supervised classifier
Transaction features + rule verdicts + analyst dispositions → fraud score.
- Graph ML mule-ring detector
Transaction network analysis for circular and burst patterns.
- Per-account velocity baselining
A personal baseline per customer; anomalies surface as contextual signal.
- Synthetic fraud generation
A simulator plus an LLM produce fraud scenarios for training and regression tests.
Case dispositions feed the training loop. Every analyst decision makes the model sharper for the next one.
Engineered to never slow your switch down.
- P50 latency 30ms Average decision
- P99 latency 200ms Worst case per SLO
- Hard cap 500ms Circuit breaker
- Throughput 2k+tps Design target, 4 channels
Decision latency, 0–500 ms
30 msp50 200 msp99 500 mshard cap
Proven under full observability
p99 under 200 ms at a sustained 400 TPS with end-to-end OpenTelemetry tracing, Prometheus metrics and Loki logging on — a production posture, not an uninstrumented benchmark.
Fail-safe policy per bank
If Guardian cannot decide in time, the bank’s configured fallback (fail-open or fail-closed) takes over — the switch never hangs.
Your fraud ops team is productive on day one.
Live transaction feed Live
Channel Amount Rule fired Decision · risk
QRIS Rp 85.000 — Approve · 0.04
BI-FAST Rp 47.500.000 New Beneficiary Block · 0.93
ATM Rp 1.000.000 — Approve · 0.07
Mobile Rp 10.000.000 Round Amount Anomaly Block · 0.81
EDC Rp 640.000 Geographic Anomaly Approve · 0.22
- 01
Live transaction feed
Every transaction and decision streams in real time. Filter by channel, rule, decision and risk score — see fraud as it happens, not in tomorrow’s report.
- 02
Case detail
Drill into a blocked transaction: which rule fired, on what evidence, at which threshold. Disposition the case, add notes, link to the customer’s fraud history.
- 03
Agent co-pilot, in the UI
Describe a pattern and the agent proposes and dry-runs a rule. Open a case and it explains why, cites evidence and suggests a disposition. The analyst decides.
- 04
Alert channels
Email, Slack, Telegram and webhook — routed per rule and per severity, into the ops stack your analysts and risk committee already use.
On-premise. Your data. Your infrastructure.
Your data centre
Deployment
- Docker Compose install in your data centre
- No data leaves your network — none
- LGTM observability included (Prometheus, Loki, Tempo, Grafana)
- Configurable retention windows for logs, metrics and transactions
Security & identity
- OIDC federation with Keycloak, AD FS or your IAM
- Tokenization at ingress — no PAN in Guardian state
- Encryption at rest for transactions, cases and audit
- PCI DSS-aware engineering patterns from day one
- Multi-tenant data shape, single-tenant install
Built for the Indonesian banking regulatory landscape.
- POJK 11/2022
Operational resilience
Active real-time controls, configurable fallback behaviour and an observable latency budget — direct evidence against operational-resilience expectations.
- POJK 38/2016
Risk management integration
Every decision is recorded with the rule that fired, the evidence used and the analyst disposition — flowing straight into your enterprise risk-management posture.
- Bank Indonesia
Payment fraud controls
Real-time blocking on BI-FAST and channel payments; the cross-channel correlation roadmap addresses the fraud-pattern gap Bank Indonesia keeps highlighting.
- OJK audit
Explainable audit trail
Every decision is immutable, timestamped and exportable. The v1.1 roadmap adds regulator-ready exports, including POJK-format audit packs.
- PCI DSS
Scope-aware by design
Tokenization at ingress, encryption at rest, zero PAN in logs — patterns designed to minimise PCI DSS scope as the bank pursues formal certification.
- Localization
Bahasa Indonesia ready
The analyst UI is built for Bahasa Indonesia localization (v1.1). Audit exports and regulator artefacts follow Indonesian conventions throughout.
Operational resilience
Active real-time controls, configurable fallback behaviour and an observable latency budget — direct evidence against operational-resilience expectations.
Risk management integration
Every decision is recorded with the rule that fired, the evidence used and the analyst disposition — flowing straight into your enterprise risk-management posture.
Payment fraud controls
Real-time blocking on BI-FAST and channel payments; the cross-channel correlation roadmap addresses the fraud-pattern gap Bank Indonesia keeps highlighting.
Explainable audit trail
Every decision is immutable, timestamped and exportable. The v1.1 roadmap adds regulator-ready exports, including POJK-format audit packs.
Scope-aware by design
Tokenization at ingress, encryption at rest, zero PAN in logs — patterns designed to minimise PCI DSS scope as the bank pursues formal certification.
Bahasa Indonesia ready
The analyst UI is built for Bahasa Indonesia localization (v1.1). Audit exports and regulator artefacts follow Indonesian conventions throughout.
Why Matajari — and how a pilot runs.
Fits the infrastructure you already have
- Any switch
Way4, Postilion or a custom stack — Guardian speaks standard authorization protocols.
- Any bypass rail
Mobile gateway, internet banking, open API, branch systems — plug in directly, no switch detour required.
- Any rule set
Channels, rules and thresholds are configured at runtime through the admin API — no schema migration, no redeploy.
- Your IAM and ops stack
OIDC federation (Keycloak, AD FS, custom), webhook alerts to Slack, email or Telegram, and audit exports in the formats your team uses.
PT Matajari Mitra Solusi
An Indonesian fintech vendor. Local engineering, local support and local regulatory understanding — built in Jakarta for Indonesian banking.
Pilot proposal
4 to 8 weeks- 1 Deploy in your sandbox
Docker Compose install inside your network, OIDC federated to your IAM.
- 2 Replay historical transactions
Dry-run the rule engine against your historical transaction tape. Measure detection rate and false-positive rate.
- 3 Analyst enablement
Dashboard training, rule-tuning playbooks and alert-channel integration with your ops tools.
- 4 Decision report to risk committee
Formal findings, a regulatory-fit assessment and a go / no-go recommendation backed by your data.
Let’s design the pilot — talk to us to schedule a technical session.
Frequently Asked Questions
Everything you need to know about Guardian.
Guardian is a real-time, agentic fraud detection system (FDS) for Indonesian banking. It sits in front of core banking and approves or blocks each transaction in under 200 ms, before funds move.
No. Card rails reach Guardian through your switch with a standard authorization protocol — no change to your switch integration. Rails that bypass the switch, such as the mobile app, open API or branch systems, plug in directly.
A hard cap of 500 ms acts as a circuit breaker, and the fail-safe policy you configure (fail-open or fail-closed) takes over, so the switch never hangs.
No. Guardian is installed with Docker Compose in your own data centre, and the AI agent runs on a local LLM inside your network — no third-party API.
Only if the bank decides so. ML moves from shadow to advisory to enforcing under the bank’s control, and enforcing requires explicit opt-in and months of shadow-mode evidence.
With a 4-to-8-week pilot: deploy in your sandbox, replay historical transactions, enable your analysts, and present a decision report to your risk committee.