Project overview

RISK & DECISION · SC-19

Fraud Detection & Explainability System

A cost-sensitive fraud scoring system with threshold optimization, explanations and investigation prioritization.

Starting point

Accuracy alone cannot choose a lending, fraud or review threshold. The business needs expected loss, false-positive cost and capacity constraints.

01 · BUSINESS PROBLEM

Risk decisions fail when the score is separated from the cost of being wrong.

Accuracy alone cannot choose a lending, fraud or review threshold. The business needs expected loss, false-positive cost and capacity constraints.

01

Wrong threshold

A technically strong model can create a poor operating decision.

02

Hidden trade-off

False positives and false negatives have different economics.

03

No explanation

Material decisions need inspectable drivers.

02 · DECISION LOGIC

From probability to an explicit risk decision.

The operating threshold is chosen using cost, risk appetite and review capacity.

Decision sequence

Each stage answers a different operating question

01Estimate

Produce a calibrated risk score.

02Explain

Expose material drivers.

03Threshold

Price the cost of each error type.

04Decide

Approve, review, decline or investigate.

Decision rule — The best threshold is a business decision supported by model evidence.

03 · WHAT CHANGED

Risk model, economics and decision logic in one path.

Prediction is connected to expected cost, explanation and review workflow.

01

Calibrate the probability estimate.

02

Measure performance beyond accuracy.

03

Optimize the operating threshold under explicit costs.

04

Expose explanations and review queues.

04 · ARCHITECTURE

A modular path from input to decision.

Inputs → preparation → core logic → validation → decision output

SC-19 · SYSTEM ARCHITECTURE

Inputs → preparation → core logic → validation → decision output

Public portfolio implementation

Inputs

01

Source signals

Capture the operating inputs required by the system. [Python]

02

Preparation layer

Normalize context and create a stable analytical contract. [XGBoost]

Core system

03

Core engine

Run the main analytical or automation logic. [SHAP]

04

Decision logic

Apply the rule, model or orchestration logic that changes the decision. [Scikit-learn]

Validation

05

Validation

Test outputs against explicit quality criteria. [Imbalanced-learn]

06

Controls

Keep approvals, thresholds or constraints visible. [FastAPI]

Decision output

07

Decision output

Expose the result in a form the user can act on. [PostgreSQL]

08

Monitoring

Record outcomes, exceptions and evidence for iteration. [Plotly]

Integration boundaries

Python

Defined responsibility inside the system; replaceable if another tool fits the requirement better.

XGBoost

Defined responsibility inside the system; replaceable if another tool fits the requirement better.

SHAP

Defined responsibility inside the system; replaceable if another tool fits the requirement better.

05 · EVIDENCE & ECONOMICS

Measure what changes the decision.

Public implementation, inspectable technical proof and decision-focused validation.

Risk evaluation

PR AUC

0.58

Representative public example.

Fraud recall

82%

Representative public example.

False positives

3.4%

Representative public example.

Decision coverage

Thresholds tested

15

Representative public example.

Validation cases

50k

Representative public example.

Reference economics

10k

Reference scenario

1 pp

Illustrative improvement

100

Decision value

06 · TECHNICAL PROOF

Review the code behind the project.

Tools used

Python01
XGBoost02
SHAP03
Scikit-learn04
Imbalanced-learn05
FastAPI06

BUSINESS CONCLUSION

Risk modelling creates value when it improves the decision threshold.

The commercial outcome comes from better allocation of risk and review capacity, not from a higher headline accuracy.

Tell us about a similar problem