When you apply for a credit card, the bank has seconds to decide: Are you a legitimate customer or a fraudster? Recently, sophisticated fraud rings bypassed our 'High Risk' security layer using high-quality fake IDs and 'lookalikes,' draining millions in unsecured funds. To stop the financial bleeding, banks were forced to route 100% of applicants to manual review, causing multi-day delays.

Through a cross functional audit, we identified two structural failures.

Vendor Signal Degradation
The immediate cause of the incident was that our identity verification vendor, MiTek, could not reliably distinguish high-quality fake IDs.

Inflexible Risk Decisioning
The deeper product failure was that we designed the system assuming identity verification would always be reliable. When that signal degraded, the product had no way to adjust risk logic.

The Hypothesis:
We hypothesized that a tiered risk engine would enable banks to dynamically adjusting mitigation strength, reducing reliance on engineering to maintain fraud controls.

1. Fixed Fraud Score:
We were redesigning the operational response to fraud, not the detection. The system had to accept the fixed Fraud Score (0.00–1.00) as an immutable input. My design had to act as a "Decision Layer" that translated that raw number into action.

2. Regulatory Compliance:
To comply with the FCRA, we cannot legally "auto-reject" an applicant based on a non-regulated tool (like an email checker).

3. User Variance:
We serve both massive banks with fraud teams and small credit unions with non fraud teams. The tool had to be powerful enough for experts to customize, but safe enough for novices to use on "Autopilot."

We allowed banks to choose which identity verification provider to use, such as MiTek or Microblink. Internal testing showed that Microblink was more effective at detecting high-quality fake IDs and offered lower per-verification costs.

I introduced a tier-based risk engine that defines exactly what checks run according to different risk tiers. Instead of relying on a vague “High Risk Mitigation” setting, each tier now triggers specific, configurable checks (ex. identity verification, bank verification, and phone checks).

To support different institutions:

Credit unions launch with smart defaults based on industry best practices and can go live safely without touching configuration.

Large banks can unlock a logic builder to customize every rule and mix verification vendors to match their risk models.

Because we gave users more power, we had to make sure they understood FCRA regulations. If a user tries to create a rule that says "Reject if Email Check Fails" (which is illegal because Email checks aren't CRA-approved), the system acts as a guardrail. It prevents the save and guides them to add an "OR" condition to satisfy the legal requirement.