Suppose a customer makes:
₹2,500 paid to SwiggyThe banking system initially only knows:
Merchant = Swiggy Amount = ₹2,500 Date = 10-Sep
PFM = Personal Financial Management wants to convert that into:
Category = Food Subcategory = Food Delivery
Then it can generate:
Monthly Food Spend = ₹8,500 Monthly Shopping = ₹12,000 Monthly Travel = ₹5,000
The ML model performs the categorization.
CUSTOMER TRANSACTION
|
v
+--------------------+
| Transaction System |
| / Payment System |
+---------+----------+
|
v
+---------------+
| Kafka / Event |
| Bus |
+-------+-------+
|
v
+---------------------+
| Feature Engineering |
| Pipeline |
+----------+----------+
|
v
+--------------------+
| Transaction |
| Categorization ML |
| Model |
+---------+----------+
|
+---------+---------+
| |
v v
+----------------+ +----------------+
| Category | | Confidence |
| Food | | 0.94 |
+-------+--------+ +----------------+
|
v
+--------------------+
| PFM Transaction DB |
+---------+----------+
|
v
+--------------------+
| Spend Analytics |
| / Insights Engine |
+---------+----------+
|
v
+--------------------+
| Mobile / Web App |
+--------------------+
MLOps CONTROL PLANE
-------------------
Training Data
|
v
+---------------+
| Model Training|
+-------+-------+
|
v
+---------------+
| Model Registry|
| v1 / v2 / v3 |
+-------+-------+
|
v
+---------------+
| CI/CD |
+-------+-------+
|
v
Production Model
^
|
+-------+---------+
| Model Monitoring|
+-------+---------+
|
Accuracy / Drift
|
Drift detected?
|
YES
|
v
Retraining Job
|
+------------> Model Registry
Example:
Customer → ₹1,200 → Amazon
The transaction event goes into Kafka.
Why Kafka?
Because you don't want the transaction processing system to wait for ML processing.
The system creates features such as:
merchant = Amazon amount = 1200 transaction_type = UPI time = 20:30 historical_merchant_category = Shopping customer_history = Shopping
These features are sent to the model.
Model returns:
Category = Shopping Confidence = 96%
You can imagine the API as:
POST /categorize
{
"merchant": "Amazon",
"amount": 1200,
"payment_type": "UPI"
}
Response:
{
"category": "Shopping",
"confidence": 0.96
}
Transaction
|
+--> Category
+--> Subcategory
+--> Confidence
Stored in PFM data store.
Now the analytics layer can calculate:
Food ₹8,500 Shopping ₹12,000 Travel ₹5,000 Bills ₹15,000
The application can show:
"Your shopping expenditure increased 25% this month."
This is what you need to understand very well.
The model is not:
Train once → Deploy → Done
Instead:
Training | v Model v1 | v Production | v Monitoring | +---- Accuracy ↓ | +---- Data Drift | +---- Prediction Drift | v Retraining | v Model v2
Think of Model Registry as GitHub for ML models.
Model Registry transaction-model | +-- v1.0 +-- v1.1 +-- v2.0 +-- v2.1
You know exactly which model is running in production.
This is extremely important for an interview.
Suppose the model was trained in 2024.
At that time:
UPI merchants Amazon Flipkart Swiggy Zomato
But in 2026 new merchants appear.
The distribution changes.
Old data Amazon 20% Flipkart 15% Swiggy 10% New data QuickCommerce merchants Digital subscriptions New UPI merchants
The model starts becoming less accurate.
That's model/data drift.
The monitoring system detects:
Accuracy < threshold
or:
Data distribution changed significantly
Then:
Drift
|
v
Retraining Pipeline
|
v
Training Dataset
|
v
Train Model
|
v
Evaluate Model
|
Accuracy > threshold?
/ \
NO YES
| |
Reject Register
|
v
Deploy
Don't say:
"I built the complete ML platform."
Instead:
"I was involved in introducing the early MLOps practices around the PFM transaction-categorization models. The key idea was to move from a static model deployment approach toward a lifecycle where model versions were tracked, production performance was monitored, and degradation or drift could trigger retraining."
Then explain:
"The transaction flow itself was event-driven. Transactions were consumed, features were generated, the categorization model predicted the category, and the result was persisted for the PFM insights layer."
That's credible and technically strong.
Now this is different.
Here the objective isn't:
"What category is this transaction?"
It is:
"Is this transaction suspicious?"
Example:
Customer normally: India ₹500 - ₹5,000 UPI Normal hours Suddenly: US ₹2,50,000 New merchant 3:00 AM New device
The fraud engine should flag it.
PAYMENT REQUEST
|
v
+-------------------+
| Payment Gateway |
+---------+---------+
|
v
+-------------------+
| Fraud Detection |
| Engine |
+---------+---------+
|
+----------+----------+
| |
v v
+-----------+ +-------------+
| Real-time | | Customer / |
| Features | | Transaction |
+-----+-----+ | History |
| +------+------+
| |
+----------+-----------+
|
v
+-------------------+
| Rule Engine |
+---------+---------+
|
v
+--------------------+
| Risk Decision |
+--------------------+
/ | \
/ | \
v v v
APPROVE REVIEW DECLINE
| | |
v v v
Payment Fraud Ops Block
Transaction:
Amount = $4,000 Country = US Device = New Merchant = New Customer = India Time = 3 AM
Rules might be:
Rule 1:
New device + high amount
→ suspicious
Rule 2:
New country + high amount
→ suspicious
Rule 3:
Multiple transactions within 1 minute
→ suspicious
Each rule produces a signal.
Rule 1 → +30 Rule 2 → +25 Rule 3 → +40 Total = 95
Then:
0 - 30 → LOW 31 - 70 → MEDIUM 71 - 100 → HIGH
Decision:
HIGH → Manual Review / Decline
This is an important interview question.
Because rules provide:
You can say:
"Transaction was flagged because it came from a new device and unusual geography."
ML might simply say:
Fraud probability = 0.92
Rules are therefore useful for:
Usually real systems use rules + ML, not only one.
PayPal operates across many countries.
So the architecture might look like:
Global Transactions
|
+---------------+---------------+
| | |
v v v
US Region EU Region APAC
| | |
+---------------+---------------+
|
v
Fraud Platform
|
+----------+----------+
| |
v v
Rule Engine Risk Models
| |
+----------+----------+
|
v
Risk Decision
The important architectural concepts are:
Fraud detection cannot take 5 seconds if you're trying to authorize a payment synchronously.
"My contribution was around the fraud-detection framework, particularly the data models and rule-based detection layer. The architecture evaluated transaction and customer signals in real time, applied configurable fraud rules, generated risk indicators, and routed suspicious transactions for review."
If asked:
Say:
"No, my involvement was more on the platform and detection-framework side rather than developing the underlying ML algorithms."
That is a much safer answer.
This is the most interesting one.
Here the ML model produces something like:
Transaction Risk Score 0.01 → Very Low Risk 0.35 → Medium Risk 0.92 → Very High Risk
TRANSACTION
|
v
+-------------------+
| Event / Streaming |
| Platform |
+---------+---------+
|
v
+-------------------+
| Feature Pipeline |
+---------+---------+
|
+----------+----------+
| |
v v
Transaction Features Historical Features
| |
+----------+----------+
|
v
+-------------------+
| Risk Scoring Model|
| |
| Model v12 |
+---------+---------+
|
v
Risk Score
0.87
|
v
+-------------------+
| Fraud Decision |
| Engine |
+---------+---------+
|
+------+------+
| |
v v
APPROVE REVIEW
MLOps
-----
Training Data
|
v
Feature Pipeline
|
v
Model Training
|
v
Model Evaluation
|
v
Model Registry
|
v
Deployment
|
v
Production
|
v
Monitoring
|
+---- Performance degradation
|
+---- Feature drift
|
+---- Prediction drift
|
v
Retraining
Suppose the model requires:
transaction_amount customer_age merchant_history device_history transaction_frequency country previous_fraud_count
You don't want developers manually prepare this every day.
Instead:
Raw Transactions
|
v
Feature Pipeline
|
+--> Cleaning
|
+--> Transformation
|
+--> Aggregation
|
+--> Validation
|
v
ML Features
Example:
Raw: Customer A 10 transactions ₹5,000 each
Pipeline calculates:
transactions_last_24h = 10 amount_last_24h = ₹50,000 average_amount = ₹5,000
These become ML features.
You don't just monitor:
CPU Memory Latency
You also monitor model health.
For example:
Model Performance Precision 94% Recall 91% False Positive 6% Prediction Latency 45ms
And:
Feature Drift amount NORMAL device_type NORMAL country DRIFT merchant_category DRIFT
Imagine:
January Precision = 95% Recall = 92%
Six months later:
Precision = 82% Recall = 76%
Something changed.
Possible reasons:
New fraud pattern
|
New merchants
|
New payment methods
|
Customer behavior changed
|
Feature distribution changed
Therefore:
Monitoring
|
v
Detect degradation
|
v
Investigate
|
v
Retrain
|
v
Evaluate
|
v
Deploy
You should remember them like this:
ML SYSTEM
|
+-----------+-----------+
| | |
v v v
IDFC PayPal PayPal
PFM Fraud Risk Score
| | |
v v v
Categorize Detect Predict
transaction fraud risk
| | |
v v v
Food/Travel Rules + ML Risk Score
| | |
+-----------+-----------+
|
v
MLOps
|
+-----------+-----------+
| | |
v v v
Versioning Monitoring Retraining
This is probably the single most important diagram for your interviews.
+----------------+
| Training Data |
+-------+--------+
|
v
+----------------+
| Feature |
| Engineering |
+-------+--------+
|
v
+----------------+
| Model Training |
+-------+--------+
|
v
+----------------+
| Model |
| Evaluation |
+-------+--------+
|
Good Model?
/ \
NO YES
| |
Reject v
+----------+
| Registry |
+----+-----+
|
v
Deployment
|
v
Production
|
v
Monitoring
/ \
/ \
Healthy Drift
| |
| v
| Retraining
| |
+-----------+
"MLOps is basically applying software engineering discipline to the complete ML lifecycle — data, features, training, model versioning, deployment, monitoring and retraining."