An attacker creates a fake ERP connector that generates synthetic or manipulated transaction data. If accepted, fabricated retailer payment histories flow into the Bronze layer and corrupt AltScore credit profiles. At scale, this could be used to inflate scores for retail borrowers controlled by the attacker, enabling fraudulent loan approvals.

• mTLS client certificates required on all connector connections; certificates are distributor-specific and issued by AltScore CA
• Payload HMAC-SHA256 signature verified at ingestion endpoint; unsigned payloads rejected
• Isolation Forest anomaly detection flags statistically improbable synthetic payment patterns
• Per-distributor data hashing and chain-of-custody: each batch references prior batch hash
• Manual audit of any distributor with sudden dramatic score distribution shift across their retailer network

A man-in-the-middle attacker intercepts the connector's outbound data upload and modifies invoice amounts, payment dates, or return rates before they reach AltScore's ingestion endpoint. Modified data flows into scoring pipeline, generating incorrect credit profiles.

• TLS 1.3 with certificate pinning prevents MITM interception
• HMAC signature covers entire payload; any byte modification invalidates signature
• Static IP allowlisting reduces MITM opportunity surface
• Ingestion endpoint validates signature before writing any data to Bronze

A distributor employee (or the distributor themselves) deliberately modifies ERP records before the connector sync — altering a retailer's payment history to inflate their score (in exchange for a bribe from the retailer) or to damage a competitor retailer's creditworthiness. Unlike a technical exploit, this threat originates from a trusted data source.

• Multi-distributor cross-validation: if a retailer has data from 2+ distributors, both must agree on payment behavior
• Isolation Forest detects anomalous patterns in payment recording that differ from the distributor's broader network behavior
• Statistical consistency checks: a distributor where 80% of retailers suddenly improve payment behavior triggers a review
• Contractual deterrent: data partnership agreement includes a fraud and manipulation clause with financial penalties and termination rights
• ERP audit log comparison: connector reads directly from ERP; ERP's own audit log should reflect the changes — if connector data doesn't match ERP audit trail, alert raised

An attacker compromises the AltScore SDK distribution pipeline and ships a malicious SDK version to distributors. The malicious SDK extracts broader data from the ERP than the declared scope (e.g., bank account numbers, personal guarantor data), exfiltrates it, or plants a backdoor that allows the attacker to inject data into future sync batches.

• SDK binary is code-signed; distributors must verify signature before installation
• SDK updates delivered only via signed, integrity-verified package
• SDK distribution pipeline is separate from the main application deployment pipeline (blast radius containment)
• SDK open-source core components with pinned, audited dependency versions
• Outbound data from SDK is schema-validated against published extraction spec before transmission; fields outside spec are stripped (defense in depth even if SDK is compromised)

A compromised service account or misconfigured IAM policy allows a data pipeline job for Distributor A to read Bronze-layer data belonging to Distributor B. This is the highest-impact information disclosure scenario — a distributor's competitor could access their full retailer transaction history.

• Per-distributor S3 prefix with separate CMK — key boundary is a hard technical barrier
• IAM policies scoped to specific prefixes; no wildcard S3 ARNs in any policy
• Spark jobs run with distributor-scoped IAM roles; cross-prefix reads are denied at the IAM level
• Quarterly IAM policy review; alerts on any cross-prefix access attempt
• Data lake access logging enabled; all GetObject calls logged with caller identity

An attacker with write access to the Bronze layer modifies or deletes raw ERP records after ingestion. This breaks the audit lineage — it becomes impossible to trace a score back to its source data. Could be used to cover up previous data manipulation or to impede regulatory investigation.

• S3 Object Lock (WORM mode) on Bronze layer — objects cannot be modified or deleted for the retention period
• Batch hash chain: each batch records a hash of all prior batches; any modification breaks the chain (detectable)
• Separate backup to a second region with independent access credentials
• Data ops service accounts have PutObject only; no DeleteObject or overwrite capability

An attacker with access to the Silver (pseudonymized) feature store attempts to re-identify a retailer by combining feature values (e.g., unique combination of GMV range + district + SKU category) with external knowledge about specific retailers in a geography. If successful, PII protections in the Silver layer are undermined.

• k-anonymity analysis run at feature computation time — any feature combination unique to fewer than k=5 retailers is generalized (binned or suppressed)
• Geographic features binned at district level, not shop-location level
• Silver layer access restricted to ML Engineers + automated pipelines; no analyst direct access
• Identity resolution store (UUID → GST/phone mapping) physically separated; ML pipeline has no access

An attacker who has compromised a distributor's ERP injects systematically manipulated training data into the NBFC partner repayment dataset — e.g., marking bad borrowers as repaid, or reporting good borrowers as defaulted. Over multiple training cycles, the model learns incorrect associations and begins systematically mis-scoring retailers in the attacker's favor. This is a slow, high-impact attack that may not be detected until default rates spike significantly above predictions.

• NBFC partner repayment data ingested via a separate, dedicated secure channel — not the same pipeline as ERP data
• Cryptographic hash of every training dataset snapshot; hashes stored immutably in WORM storage
• Champion/challenger model evaluation: new model version must outperform champion on a holdout — manipulated training data would create a weaker model, not a stronger one (in most cases)
• Continuous monitoring of predicted PD vs. actual default rate per distributor cohort — systematic manipulation by one distributor creates a detectable deviation in that cohort
• Annual adversarial data injection test (red team) to validate detection capability

An attacker with API access systematically queries the Score API with modified inputs for the same retailer (or similar synthetic retailers), studying how the score changes in response to feature variations. Over many queries, the attacker reconstructs the model's decision boundary — effectively reverse-engineering the scoring logic to either game it or sell the knowledge to competitors.

• API does not accept arbitrary feature inputs — only retailer_id; features are computed internally and not exposed
• Rate limiting: max 3 score queries per retailer per 24h per lender — limits systematic probing
• Reason codes are categorical labels, not numeric feature values; labels reveal direction, not magnitude
• Model score output includes controlled noise for borderline cases (score ±5 for P(Default) within 1% of band boundary)
• Anomaly detection on lender query patterns — systematic probing of many retailers with minor variations triggers review

A retailer who learns (through their distributor or a leaked reason code pattern) which behaviors improve their score deliberately inflates orders before a scoring event, makes unusually punctual payments for a short period, or avoids returns — without a genuine underlying business improvement. If successful, they receive a higher credit limit than their actual risk profile warrants, leading to over-lending and eventual default.

• Isolation Forest detects order velocity spikes >3σ from 12-month baseline
• 60-day look-back window — manipulation must be sustained for 2 months, which requires actual behavior change
• Long-term payment history (3+ years) dominates the payment signal; 2-month improvement minimally affects band
• Return rate counter-signal: inflated orders are often returned; high returns penalize even if orders are high
• Reason code opacity: retailers see categories ("consistent_order_frequency"), not the specific numerical thresholds

An attacker with access to the model registry modifies the serialized XGBoost model artifact or the feature scaler objects — introducing a backdoor that causes specific retailer profiles (identifiable by the attacker) to receive artificially high scores. Because the model binary is serialized, the change may not be detectable through output monitoring until default rates spike.

• SHA-256 hash of all model artifacts logged at training time; hash verified at every model load
• Hash mismatch = model load failure + immediate alert to ML Ops + Security
• Model registry access restricted to ML Ops role; no developer direct write access
• Promotion of any model version requires: hash verification + performance validation on holdout + human sign-off from two ML team members
• Artifact store on S3 WORM — model artifacts are immutable after training

The model, through correlations in training data, systematically under-scores retailers in a specific geography, industry, or demographic group — not due to malicious tampering, but due to spurious correlations in historical data (e.g., a region where the NBFC partner historically denied credit, creating a self-fulfilling training signal). This is not a traditional security threat, but the harm to affected retailers is real and the regulatory exposure under DPDP Act is significant.

• Quarterly fairness audits: score distribution compared across state, district tier, trade category, and gender proxy cohorts
• Disparate impact testing — score gap >15% for matched behavioral cohorts triggers model review
• Geography excluded as a direct feature; only behavioral signals permitted
• Training data de-biasing: NBFC partner data reweighted to correct for historical denial bias if detected
• Model freeze protocol: if bias detected, model frozen and retraining initiated before next production scoring cycle

A vulnerability in the API authorization layer (e.g., an IDOR — Insecure Direct Object Reference) allows a lender to query the score of a retailer that belongs to a different lender's portfolio — one where the retailer has not consented to that lender. At scale, a single lender could enumerate the entire retail credit portfolio of a competitor NBFC.

• Row-level security (RLS) in PostgreSQL Score Store — every query automatically scoped to requesting lender_id; bypass requires DB-level privilege not available to application
• Consent scope check: API verifies retailer has consented to requesting lender before DB query is issued
• No sequential retailer IDs; UUIDs used throughout — enumeration attacks yield no useful identifiers
• Penetration testing includes IDOR testing on every release; dedicated OWASP API Top 10 test suite
• Anomaly detection: lender querying many retailers they don't have a prior relationship with → alert

A volumetric DDoS attack against the Score API makes it unavailable to lenders during a peak underwriting period (e.g., before a major festival credit surge). Lenders cannot underwrite retailers; loan disbursements are delayed; AltScore breaches SLAs with NBFC partners. Could be financially motivated (extortion) or competitive sabotage.

• Cloud-native DDoS protection (AWS Shield Advanced / Azure DDoS Standard) upstream of application
• WAF rate limiting at network layer before application-layer rate limiting
• API responses cached in Redis (TTL: 12 hours per retailer) — cached scores served even if scoring pipeline is under load
• Multi-region API deployment for failover; automated DNS failover on health check failure
• Lender SLA includes 99.5% uptime; incident comms playbook for DDoS events pre-drafted

A lender's API key is leaked (e.g., committed to a public GitHub repository, phished from an NBFC developer, or stolen in a lender-side breach). An attacker uses the stolen key to query scores within the lender's authorized retailer scope, accessing sensitive credit intelligence they are not entitled to receive.

• Compromised key revocation: lender can revoke via API or support request; revocation effective within 60 seconds
• Anomaly detection on API key usage: queries from new IP geographies, unusual hours, or sudden volume spikes trigger alert to both AltScore security and NBFC CISO
• API keys are short-lived access tokens (1h TTL) with rotating refresh tokens — a leaked key expires quickly
• Lenders advised to use IP allowlisting for their API keys; AltScore enforces this for enterprise NBFC integrations

After a loan defaults, an NBFC lender claims the score they received was different from what AltScore served, or that AltScore provided a score with stale data without adequate disclosure — in order to shift liability for the bad loan to AltScore. Without an immutable record of the exact score served, AltScore has no defense.

• Every score API response logged immutably: lender_id, retailer_id (UUID), score, PD, risk_band, model_version, data_freshness_days, generated_at, request_ip — all fields
• Score record stored in Score Store with the same values; lender API response reconstructable from stored record
• data_freshness_days prominently included in every response; lender acceptance of stale data is a documented API interaction
• Lender API agreement includes: "AltScore's audit log constitutes the authoritative record of scores served"