Risk assessment and anti-fraud almost always run into the same problem: you want to change rules and scoring every week, while the core system (core banking, billing, insurance platform) changes once a quarter and goes through a release committee. If scoring logic is embedded inside the core, every model change turns into regression testing of the entire system. An open-source Python stack makes it possible to move scoring and anomaly detection into a separate service next to the core and change models independently of the main platform's releases.
Below is an overview of what can actually be built with open-source tools. This is not a KT.Team case study, but an analysis of publicly available projects with links to the source code.
Interpretable scoring: scorecardpy and optbinning
The regulator and risk committee require explainability: why an applicant was rejected, which factor influenced the score and by how many points. That is why credit scoring is still dominated not by black boxes, but by scorecards based on logistic regression with WOE binning (Weight of Evidence).
Library scorecardpy is a Python port of the well-known R package scorecard. It covers the full workflow: sample splitting, variable selection, WOE binning, score scaling, and model quality evaluation (KS, AUC, PSI). The result is a score table that can be shown to an auditor and embedded into a credit workflow as a set of understandable weights.
optbinning solves a narrower but important task: optimal monotonic binning of features before logistic regression (WoELR). Monotonicity is not about aesthetics: it guarantees that "the worse the feature, the lower the score," which removes objections from model validators.
Business result: the scoring model remains explainable and audit-friendly, and rebuilding the scorecard is a Python pipeline run, not a release of the banking system.
Anomaly detection: PyOD and Isolation Forest
Scoring answers the question "should we grant the loan." Anti-fraud answers another one: "does this transaction look like something the customer usually does, or not." Labeled fraud examples are almost always scarce here, so unsupervised methods are used.
PyOD is the most comprehensive open-source outlier detection toolbox: more than 60 algorithms in one API, from classic Isolation Forest and KNN to autoencoders for complex patterns. A single interface makes it possible to build an ensemble of multiple detectors and compare them on the same dataset without rewriting code. Isolation Forest remains a workhorse for large volumes: it quickly isolates unusual points and produces an anomaly score without requiring labels.
Business result: new fraud schemes, for which there are not yet labeled cases, are caught by deviation from normal behavior rather than by a predefined rule.
Real-time features: Feast
At the moment of the transaction, both scoring and anti-fraud rely not on the raw payment field, but on aggregates: how much the customer spent in an hour, the average ticket over 30 days, transaction frequency. Calculating them on the fly at authorization time is expensive and slow.
Feast An open feature store that keeps precomputed features in a low-latency online store (for example, Redis) and serves them to the model in milliseconds. In the official fraud detection tutorial An end-to-end scenario is shown: streaming pipelines calculate behavioral features, and the model decides in real time whether a transaction is fraudulent. The key advantage is that the same feature definitions are used both in training and online, eliminating train/serving drift.
Ready-made platform: Jube
If you do not want to assemble the service from building blocks, there is an open platform Jube (AGPL-3.0 license) for real-time transaction monitoring, anti-fraud, and AML. It combines a hybrid engine (rules + ML), case management for investigations, checks against velocity, aggregates, and sanctions lists. The architecture is stateless and horizontally scalable, state is kept in Redis, and integration is synchronous over HTTP or asynchronous through RabbitMQ. This is an example of how an anti-fraud layer sits next to the core and communicates with it over the network rather than being built into it.
Architectural principle: next to it, not inside it
The common denominator of all four projects is that scoring and anti-fraud live as a separate service and integrate with the core system through API or queue. This is the "minimal intervention in the core" approach: the transaction system is not modified for every new model, it only calls the scoring service and receives a decision. The data science team deploys new model versions independently of the release cycle of the banking or insurance platform.
Schematic flow description
The core system (core banking / payment gateway / insurance platform), when a "new transaction" or "new application" event occurs, makes a synchronous HTTP call (or puts a message into RabbitMQ) to the Python scoring/anti-fraud service. The service enriches the event with precomputed features from Feast (an online store in Redis), runs it through a scorecard (scorecardpy/optbinning) and/or an anomaly detector (PyOD / Isolation Forest), and returns a score and a decision (approve / review / decline). Suspicious cases go into an investigation queue (case management modeled after Jube), and the investigation outcome is returned to the training set for model retraining. The core does not change - it only calls the service and reads the response.
Business Outcome
The main measurable effect is the speed of changing risk logic. When scoring and anti-fraud are moved into a separate Python service, a new model or rule version can go live in days, not on the core's quarterly release cycle. The core system stays stable and unpatched, and the risk team gets an independent layer that can be handed off to another team or contractor without rewriting the banking platform.
