Pine Labs · Fraud risk platform · Under NDA
FRM Dashboard
A fraud rule engine a bank's own risk team could operate. Nine modules, issuing and acquiring, without an engineer standing behind every rule.
- Role
- Research, solutioning, UX
- Ownership
- Sole designer, 9 modules
- Worked with
- PM, engineering, risk and ops
- Timeline
- Around 2 to 3 months
The problem
“Decline a card after five ₹1 transactions in a row” is a sentence a risk analyst can say out loud in seconds. Turning it into a live rule took an engineering ticket. Pine Labs had a business requirements document and an existing Helpdesk module. What it did not have was a way for a bank's own risk team to write, approve and run fraud rules themselves, across issuing and acquiring, in one platform.
Why it was hard
Boolean logic for people who don't write it
Real fraud patterns need conditions joined by AND/OR, each with its own nested sub conditions, drawn from around eighteen transaction attributes: amount, merchant category, BIN, POS entry mode, origin, time. Expose that raw and it is a query builder. Oversimplify it and it cannot catch anything real.
One engine, many vocabularies
The same rule builder had to serve issuing and acquiring, multiple banks, and workflows spanning FRM, ACS, UPI and AML. Onboarding an institution was its own module, covering region, time zone and account number length, because every bank arrived with a different assumption about what a transaction even looks like.
Nine modules that had to agree with each other
A rule is written, approved through a workflow, fires an alert, becomes a case, and has to be reportable afterwards. Separate screens, but one object moving through all of them. The navigation changes by permission level too, so an admin and a super admin are effectively using different products. Half of it had to live inside a legacy Helpdesk shell that could not stop running.
The call I made
I drew twenty plus complete rules instead of one rule template.
The requirements document said a rule can have conditions. It could not tell me where that breaks. So the rule configuration alone ran to roughly 300 screens: real permutations across the actual attribute set, nested sub conditions, CSV uploaded lists, combinations that contradicted each other, until new permutations stopped producing new failures.
Design the rule builder once in its default state, document how it is meant to flex, and let engineering resolve the combinations as they hit them. Far fewer screens, and the standard way this gets handed over.
Draw the permutations until they stopped surprising me. Every scenario that broke the pattern was found in a design file rather than in production, on a system whose entire job is catching fraud.
What shipped
Rule Management.
Status, owner, priority and audit trail for every rule. The workflow column is where FRM, ACS, UPI and AML all sit on the same engine.
Case Management.
Case Management, built inside the legacy Helpdesk. It already had a ticketing structure much like case work, so we extended it rather than building a second one.
Workflow Definition.
Workflows are defined per institution, and rules resolve by match-all or by priority when they collide.
How it landed
Designed end to end and taken into development as the rule configuration layer for Pine Labs' fraud risk tooling, covering issuing and acquiring in one platform.
screens designed across the platform
complete rule permutations drawn out
modules, two permission levels
Scope rather than impact. No usage figures available under NDA. Built in roughly two to three months, overlapping the CardHolder App.
The point of all of it is that a risk analyst can write, test and pause a fraud rule without me or an engineer in the room. Designing myself out of the workflow was the outcome I was after.
In hindsight
Looking back, it should have been built to extend the Helpdesk rather than sit beside it as an addition. The next team inherited two systems to reconcile instead of one to build on.