Credit Build Sheet

POST /credit-report
{
  "name": "...", "dob": "1991-04-12",
  "pan": "ABCPX1234K",            # PAN is the strongest match key
  "mobile": "9xxxxxxxxx",
  "address": {...},
  "consent": {"granted": true, "timestamp": "...", "ip": "...",
              "purpose": "loan_underwriting"},   # REQUIRED. Store it.
  "bureau": "cibil"                 # or experian | equifax | crif
}

RESPONSE
{
  "score": 742, "score_name": "CIBIL_SCORE_V3",   # <- version matters
  "enquiries": [ {date, member, purpose, amount} ],
  "accounts":  [ {type, opened, sanctioned, balance,
                  dpd_history: "000|000|030|..."} ],
  "match_confidence": "exact" | "partial"
}

WHAT TO CHECK, EVERY TIME
[ ] match_confidence. A "partial" match may be a different person
    with a similar name. Do NOT decision on a partial match.
[ ] score_name / version. Cut-offs tuned on one score version are
    not valid on another. Pin the version in your policy.
[ ] "no hit" is NOT a low score. It is a thin file. Route it to the
    alt-data path, do not decline it. (See the module.)
[ ] dpd_history is a STRING of 3-char buckets, most recent first.
    Parse it; do not regex for "30" and call it a delinquency.
[ ] enquiries in the last 30-90 days - a burst across lenders is one
    of the strongest distress signals you get for free in this payload.
[ ] store the RAW response as evidence, not just your parsed fields.

1. CREATE CONSENT REQUEST        (you -> AA, via your TSP)
   {customer_mobile, purpose_code, fi_types:["DEPOSIT"],
    from_date, to_date, frequency, data_life, consent_expiry}
   -> {consent_handle, redirect_url}

2. USER APPROVES                 (user -> AA app/webview)
   They pick which accounts to share. THEY MAY PICK NONE.

3. CONSENT NOTIFICATION          (AA -> your webhook)
   {consent_handle, status: ACTIVE|REJECTED|EXPIRED}

4. REQUEST DATA                  (you -> AA)
   {consent_id, from_date, to_date}  -> {session_id}

5. FETCH                         (you -> AA)
   GET /FI/fetch/{session_id}  -> encrypted payload, you decrypt

WHERE IT ACTUALLY BREAKS
[ ] Step 2 drop-off is the single biggest number in this flow.
    Instrument it per screen. It is usually 30-50% and it is mostly
    a UX problem, not a consent problem.
[ ] The user may share ONE account of five. Check account count
    against what your policy assumes before scoring.
[ ] from_date/to_date must be within what the FIP actually retains.
    Asking for 24 months when the bank holds 12 returns 12, silently.
[ ] data_life and consent_expiry are DIFFERENT. data_life is how long
    you may keep it; expiry is how long you may fetch. Set both
    deliberately - DPDP purpose limitation applies.
[ ] Some FIPs are slow or intermittently down. Build for a partial
    fetch and a retry, not a single synchronous call.

RESPONSE (shape is broadly common across vendors)
{
  "accounts": [{
     "bank": "...", "account_type": "SAVINGS",
     "period": {"from": "...", "to": "..."},
     "summary": {"total_credits":..., "total_debits":...,
                 "avg_monthly_balance":..., "min_balance":...},
     "income": {"salary_credits": [...], "confidence": 0.9},
     "obligations": {"emi_debits": [...], "monthly_emi":...},
     "flags": {"bounces": n, "circular_transactions": bool,
               "tampering_suspected": bool}
  }]
}

WHAT TO CHECK
[ ] period actually covers what you asked for. A 4-month statement
    scored against a 12-month policy is not a conservative decision,
    it is an invalid one.
[ ] the analyser's salary detection is heuristic. Verify against
    EPFO where the borrower is salaried - employer-confirmed beats
    inferred every time.
[ ] tampering flags apply to UPLOADED PDFs. AA-sourced data comes
    structured from the bank and bypasses that risk entirely -
    which is the main reason to prefer AA over upload.
[ ] bounce/return counts: confirm the vendor's definition. Some count
    inward returns only, some both directions. It changes the feature.
[ ] ask how many of the supported bank formats were UPDATED in the
    last twelve months, not how many are "supported".

import xgboost as xgb, shap, mlflow
from sklearn.model_selection import TimeSeriesSplit

# 1. SPLIT BY TIME, never randomly. Credit data has a time dimension
#    and random splits leak future information into training.
tscv = TimeSeriesSplit(n_splits=5)

# 2. TRAIN
model = xgb.XGBClassifier(
    max_depth=4,              # shallow. deep trees overfit credit data
    n_estimators=300,
    learning_rate=0.05,
    scale_pos_weight=neg/pos, # defaults are ~2-8% positive
    eval_metric="auc")

# 3. REGISTER IT - this is your model inventory entry (Module 09)
mlflow.set_experiment("pd_unsecured")
with mlflow.start_run():
    model.fit(X_tr, y_tr)
    mlflow.log_params({"population": "salaried_tier1_2",
                       "approved_use": "personal_loan_unsecured",
                       "prohibited_use": "any other product"})
    mlflow.xgboost.log_model(model, "model")

# 4. EXPLAIN - TreeSHAP exact, not the sampling approximation
explainer = shap.TreeExplainer(model)          # exact for trees
sv = explainer.shap_values(X_te)               # -> reason codes

# WHAT TO CHECK
# [ ] out-of-TIME performance, not just out-of-sample
# [ ] performance by segment, not just overall
# [ ] benchmark against logistic regression. If the gain is small,
#     the explainability burden may not be worth it.
# [ ] every feature mapped to a reason code (CI assertion in the module)