Creating a Fraud Detection Platform for the PSrE cosystem

Introducing... Tilaka Fraud Detection!

After some digging and familiarizing myself with fraud and identity products, I chose a fraud detection product as Tilaka's new product line. This is because of two things:

1. Tilaka lacks stickiness. Most of its products already serve their purpose, and most clients would only need those (e-meterai, consent, and signing products). Improvements to these product lines wouldn't really move the market that much.
2. A fraud detection product has many variables (rules, thresholds, configurations, and integrations), making it deeply embedded in clients' operations and increasing vendor lock-in, especially if we adopt a machine learning approach.

Tilaka Fraud Detection Workflow

Now let me explain how the system should work:

1. Initial Flow: After a user performs an action, the client's system sends the event to Tilaka's Fraud Detection platform. At a minimum, the request should include:

• Event information (event ID, timestamp, event type, and originating module)
• User identity information (identity ID, email address, and phone number)
• Device metadata (device ID, device type, operating system, IP address, etc.)

This information becomes the foundation for the data enrichment module, where additional trust signals are generated before the transaction is evaluated by the scoring engine.

2. Data Enrichment Module: Based on the raw data received from clients, the data enrichment module will creates more meaningful information from it:

• Digital Footprint: Based on the email address and phone number, the engine checks for potential fraud patterns using signals such as tags, linked social media accounts, and other available data.
• Velocity Data: Based on historical transaction data, the engine performs an analysis to detect unusual transaction patterns (e.g., multiple transactions within a short period of time).
• Integration With Tilaka: if the client also use Tilaka's other product, it can be also integrated as optional parameter into the Fraud Detection engine. This can provide a strong selling point and stickiness for the client 💸

3. Scoring Engine: There are two types of scoring engines we can implement (rule-based or machine learning). For the first phase, I recommend building only the rule-based engine. After gathering enough data and traction, we can start developing the machine learning model.

Scroll down to see the UI and a further explanation of the rule-based scoring engine.

4. Review Section: The confidence score is the final output of the scoring engine (0 = no fraud, 100 = fraud). Based on this score, Tilaka provides a dashboard for manually reviewing cases that fall within the middle range (e.g., a configurable threshold of 40–65).

UI/UX Tilaka Fraud Detection

Now onto the fun part, it won't be a complete study case without the UI design 😃. I created 4 UI screens for the client's dashboard, let's get right into it.

Rule-Based Scoring Engine

For the first phase, I chose a rule-based scoring engine to enable faster product rollout while collecting enough historical data for a future machine learning model.

Each row represents a fraud rule generated from the data enrichment module. Fraud analysts can configure every rule without engineering involvement through 2 main parameters:

• Status (On/Off): Enables or disables a rule. Disabled rules are ignored during score calculation.
• Score Impact: Determines how much a triggered rule changes the final confidence score. For example, +85 increases the fraud confidence score by 85 points, while -40 decreases it to represent a trusted signal.

At the bottom, a lightweight analytics section provides quick insights into rule optimization, impact trends, and recent rule activity to help fraud teams continuously improve detection performance.

Review Dashboard

The Review Dashboard is designed for fraud analysts to manually review cases that fall within the configurable confidence threshold or investigate specific subjects when needed.

The interface is divided into two main sections:

• Left Panel : Focuses on the current case, including the list of open cases. The rule breakdown makes the scoring process transparent by showing how each rule contributes to the final confidence score.
• Right Panel (Subject Context): Provides a complete view of the subject. Consolidating this information into a single panel helps analysts better understand the subject and make more informed decisions without switching between multiple systems.

Rule Builder & Simulation

One challenge of a rule-based engine is that a small configuration change can significantly impact fraud detection performance.

A rule that is too aggressive may increase false positives, while one that is too lenient may allow fraudulent transactions to pass.

To address this, every rule change should go through a simulation before being deployed to production. Instead of guessing the impact, Tilaka replays historical transaction data against the proposed rule and estimates how decision outcomes would change.

The interface is divided into two main sections:

• Left Panel: Allows fraud analysts to configure fraud rules by defining conditions, score weight, and the resulting action when a rule is triggered. This enables non-technical users to continuously refine the scoring engine without engineering involvement.
• Right Panel: Visualizes the estimated impact of the proposed rule using historical data. Analysts can understand how the rule affects review volume, approval rates, and individual cases before publishing the change, reducing the risk of unintended business impact.

Audit Logs

As a trust infrastructure provider, every automated decision and manual action should be fully traceable. The Audit Logs page provides a complete history of the fraud detection lifecycle, making investigations, internal audits, and regulatory compliance significantly easier.

The interface is divided into two main sections:

• Activity Timeline : Records every important event, from score generation and rule execution to manual reviews and rule modifications. Maintaining this history allows organizations to understand how a decision was made and who was responsible for each action.

• Audit & Integrity: Every record is immutable and can be exported for compliance or forensic investigations. This ensures the integrity of the audit trail while providing organizations with the transparency required during internal reviews or regulatory audits.

That's It!

Really had a lot of fun creating this, especially on creating the workflow😊 This study cases also gave me a lot of perspective on how PSrE companies work, not only Tilaka need to creates system that modular but also can be seamlessly integrated on client's system. Also, all system designs should prioritize usability, ensuring that even non-technical users can easily use the product.

See you on next articles👋