u/AIforFintech

Five complete projects, each solving a real problem in financial services. All with working code, architecture documentation, and a path to production.

What's in there:

Regulatory RAG for querying BSA/AML documentation, with page level citation on every answer.

Churn pipeline for banking customers, with automated feature engineering, Bayesian optimization, and SHAP explainability.

Causal inference estimating the real effect of credit limit changes on default risk. The result goes against common industry intuition.

Benchmark of 9 techniques for handling extreme class imbalance, using card fraud as the test case.

A/B test design pipeline that delivers the groups already balanced and statistically validated.

Everything open, no signup, no paywall. The idea is that any data team can clone it, understand the architecture decisions, and adapt it to their own context.

Link: https://aiforfintech.tech

Feedback always welcome, technical criticism especially.

👊

A common mistake when building fraud models is picking a resampling technique because it is popular, not because it was tested against the alternatives. SMOTE gets recommended by default, but on real fraud data it is rarely the best option.

A practical example: in a credit card fraud dataset, fraud represents 1 in every 578 transactions. A model that always predicts "not fraud" would score above 99.8% accuracy. Standard metrics like Accuracy and ROC-AUC look fine even when the model is not catching anything useful. PR-AUC is what actually tells you the truth here.

I ran a benchmark comparing 9 approaches on the same data, same split, same base model: random undersampling, oversampling, SMOTE, SMOTE-ENN, ADASYN, class weighting, Isolation Forest, and threshold tuning. SMOTE-ENN took about 15 minutes to run and finished sixth. A moderated class weight adjustment, which changes nothing in the training data and adds a single parameter, won.

Final result on the test set: 82 of 98 real fraud cases caught, with only 5 false positives out of 56,864 legitimate transactions.

Hub: https://aiforfintech.tech
Github: https://github.com/junidepieri-design/fraud-001-imbalanced-classification-benchmark

What has been your experience with SMOTE vs simpler alternatives?
👊

A common mistake when building RAG systems is relying only on semantic search. It is great at capturing meaning, but it stumbles on precise technical or legal terms.

A practical example: in banking compliance, terms like "SAR" or "structuring" have exact regulatory meaning. Semantic search might return a passage that "seems" related, but misses the exact citation. Keyword search (BM25) covers exactly that blind spot.

Combining both methods (hybrid search), the system captures both meaning and exact terms, delivering more reliable answers, especially in regulated contexts like fintech, where a wrong answer has real cost.

I applied this in a RAG project for BSA/AML documentation (US banking regulation). The precision gain in answers was noticeable, especially on questions with specific technical jargon. Simple to implement, and the reliability payoff is well worth it.

Hub: https://aiforfintech.tech

Github: https://github.com/junidepieri-design/genai-001-regulatory-rag-bsa-aml

Does this make sense for your stack too?

👊

​

Most Data Science projects in credit use classification: the model takes customer features and predicts whether they'll default or not. Works well for prioritizing portfolios and ranking risk.

But classification answers "who will default?". It doesn't answer "what caused the default?" or "if I change the credit limit, what happens?"

That's where Causal Inference comes in.

Instead of predicting an outcome, it estimates the effect of an action. Not correlation, causation. And the practical difference is huge: a classification model can tell you that customers with low limits default more. But that doesn't mean increasing the limit reduces default. The bank may have already given low limits to the riskiest customers.

Without controlling for that bias, you make the wrong decision.

In our project [CAUSAL-001], we tested exactly this: does reducing the credit limit actually reduce default risk?

Controlling for 22 confounders (payment history, bill amounts, demographics), the result was the opposite of what most assume: a one standard deviation increase in credit limit decreases default probability by 1.19 percentage points.

The likely mechanism: a higher limit reduces utilization ratio, which reduces financial pressure on the customer.

And the effect isn't uniform. Using Causal Forest, we found a small subgroup that reacts the opposite way: for them, increasing the limit increases risk.

Stack: DoWhy, EconML, Causal Forest

Hub: aiforfintech.tech

Repo: github.com/junidepieri-design/causal-001-credit-limit-intervention