Fintech Risk Engineer Interview Questions

Option B is strongest because it covers latency requirements, feature categories (transaction, behavioural, network), sliding-window feature engineering, feature store architecture, precision-recall vs AUC evaluation, false positive rate by segment, champion-challenger deployment, and threshold tiers (decline/step-up/pass-through). Option A describes the general approach without addressing latency, feature engineering, evaluation metrics, or deployment strategy. Option C describes a rule-then-ML ensemble, which is a valid pattern, but gives no detail on how the ML component works, how performance is measured, or how thresholds are set. Option D correctly identifies the class imbalance problem with accuracy but proposes no solution and names no appropriate metrics. Fintech risk engineer interview best practice: explicitly mention false positive rate and precision-recall tradeoffs — interviewers want to see that you understand the business cost of false positives, not just the fraud detection rate.

Option B is strongest because it defines KYC's components (document verification, PEP/sanctions screening, risk rating), explains structuring/layering/integration as specific money laundering typologies, describes the full technical pipeline (Kafka, Flink, case management, audit trail), and names specific regulatory outputs (STR/SAR). Option A gives accurate definitions but no technical depth on system components, typologies, or regulatory reporting. Option C correctly identifies sanctions screening as one component of AML but misses transaction monitoring, typologies, case management, and STR/SAR filing. Option D describes one specific scenario (cash threshold reporting, related to CTR filing) without explaining the broader AML monitoring system. Fintech risk engineer interview best practice: name specific money laundering typologies (structuring, layering, integration) — these terms signal real AML domain knowledge rather than generic compliance awareness.

Option B is strongest because it defines all three terms with precise detail (12-month vs lifetime PD horizons, LGD by asset class with percentage ranges, CCF for revolving facilities), explains estimation methodology (logistic regression, workout data, time value discounting), and correctly states the EL formula and its regulatory uses (IFRS 9, Basel III IRB). Option A gives accurate one-line definitions but no depth on estimation methods, asset-class variation, revolving credit complexity, or regulatory context. Option C correctly names Basel as a use case but provides no definition or estimation detail. Option D correctly describes estimation data sources at a high level but misses revolving credit EAD complexity, LGD asset-class variation, and the EL formula. Fintech risk engineer interview best practice: always state the EL formula explicitly and explain LGD variation by asset class — this shows you can move between conceptual definitions and practical implementation.

Option B is strongest because it gives a precise VaR definition with numerical example, names FRTB/Expected Shortfall as the Basel IV replacement, and systematically enumerates VaR's limitations: tail blindness, distributional assumptions, lookback window sensitivity, non-subadditivity, and the role of stress testing. Option A is a correct definition but provides no limitations, regulatory context, or comparison with Expected Shortfall. Option C identifies the tail risk limitation correctly but names no other limitations and provides no regulatory context or quantitative precision. Option D correctly identifies the Basel III VaR multiplier (3x) but provides no definitional depth, limitations analysis, or FRTB context. Fintech risk engineer interview best practice: mention non-subadditivity and Expected Shortfall specifically — these are the two most technically sophisticated VaR limitations and immediately distinguish strong candidates from those who have only memorised the basic definition.

Option B is strongest because it covers the full architecture: synchronous gRPC/REST path within payment authorisation, Redis/DynamoDB feature store with sub-millisecond reads, Flink/Kafka Streams pre-aggregation, ONNX/Triton model serving with pre-loaded memory, model complexity constraints (GBT leaf count), response payload contents, asynchronous enrichment loop back to the feature store, and circuit breakers for fallback. Option A correctly identifies Kafka and a fast model but provides no architectural detail on feature serving, model serving infrastructure, synchronous vs asynchronous paths, or failure handling. Option C identifies the correct requirements (fast database, lightweight model) without describing how to build a system that meets them. Option D describes batch pre-scoring, which cannot capture real-time transaction context (velocity in the last hour, this-session behaviour) and is therefore insufficient for transaction fraud detection. Fintech risk engineer interview best practice: distinguish the synchronous scoring path (must be sub-100ms) from the asynchronous enrichment path — interviewers probe whether you understand this separation as the key architectural constraint.