PRM common mistakes
PRM · Understand the traps and how to avoid them.
Treating operational resilience as synonym for business continuity and answering scenario questions with a pure BCP/DR playbook: invoking the disaster recovery site, restoring backups, and declaring recovery complete once systems are back online.
Candidates carry over the continuity mindset (recover assets within RTO) and miss that resilience is judged on whether important business services stay within impact tolerances during disruption, including customer harm, market integrity, and regulatory obligations, not just IT restoration. The exam scenario is usually written so that technical recovery succeeds but the impact tolerance is still breached.
What to do instead
Before answering, identify the important business service, its impact tolerance, and the harm dimension (customer, market, counterparty). Evaluate options against 'does this keep the service within tolerance during the disruption' rather than 'does this restore systems'. Practise mapping each option to prevent, respond, recover, or learn, and reject options that conflate recovery of infrastructure with continuity of service.
Assigning severity and escalation based only on the number of systems or users affected, ignoring the criticality of the business service and the time already elapsed against the impact tolerance.
Incident-management habits from IT operations rank by blast radius and ticket volume. Resilience frameworks rank by service criticality and tolerance breach trajectory, so a small outage of a payment service can outrank a large outage of an internal tool. Candidates default to the familiar IT metric.
What to do instead
For each incident question, ask which important business services are touched and how much of the tolerance has been consumed. Rank severity by service criticality multiplied by tolerance consumption, and choose escalation paths that notify service owners and risk/compliance, not just IT management.
Treating third-party and outsourcing risk as a procurement checklist item (contract signed, SLA in place) and failing to test concentration risk, subcontractor chains, and the firm's ability to substitute or exit a provider under stress.
Candidates learn vendor due diligence as a one-time onboarding gate and underweight ongoing monitoring, fourth-party exposure, and exit planning. Exam items often describe a single provider serving many critical functions, and the naive answer is 'the SLA covers it'.
What to do instead
Memorise the lifecycle: due diligence, contracting with audit and termination rights, ongoing monitoring, concentration assessment, and tested exit/substitution plans. When a scenario shows concentrated dependency, prefer answers that quantify substitutability and time-to-exit over answers that cite contractual remedies.
Confusing model validation with model performance testing: answering that a model is validated because backtesting accuracy, AUC, or RMSE is acceptable, without addressing conceptual soundness, assumption review, stability, and use-case appropriateness.
Candidates with data-science backgrounds equate validation with statistical fit. Regulatory model risk management separates developmental evidence, conceptual soundness, ongoing monitoring, and outcomes analysis, and a high-performing model can still be invalid for its intended use.
What to do instead
Structure every model-risk answer around the three pillars: conceptual soundness (theory, assumptions, data appropriateness), ongoing monitoring (stability, drift, benchmark comparison), and outcomes analysis (backtesting against realised results). If an option cites only a performance metric, treat it as incomplete.
Selecting 'more data' or 'a more complex model' as the remedy for a model that is unstable or poorly calibrated in production, rather than diagnosing data drift, population shift, or a broken feature pipeline.
The instinct that bigger models fix accuracy problems is strong, and candidates miss that production degradation usually stems from distribution shift, label leakage, or stale features. Complexity can amplify instability and reduce explainability.
What to do instead
Diagnose first: compare training and production feature distributions, check for population shift and label drift, verify data lineage and feature freshness. Choose monitoring, retraining triggers, and challenger models over architectural escalation, and prefer remedies that preserve explainability for regulated decisions.
Treating explainability and fairness as optional 'nice to have' documentation rather than as control requirements that gate deployment, especially for credit, pricing, and fraud decisions with adverse-action obligations.
Candidates focus on predictive power and treat model documentation as paperwork. In regulated settings, the inability to explain a declined decision is itself the risk event, and fairness testing is a control, not a reporting artifact.
What to do instead
For any model touching customer outcomes, require pre-deployment documentation of features, limitations, and decision logic, plus bias testing across protected groups and a human review or appeal path. When an option defers explainability to post-launch, mark it wrong.
Answering fintech questions by assuming the startup's technology-first model avoids traditional risk obligations, or conversely assuming legacy bank controls apply unchanged to a distributed-ledger or API-based model.
Candidates hold a mental split between 'fintech' and 'bank' and fail to see that the same conduct, AML, safeguarding, and operational risk obligations attach to the activity regardless of charter. Novel delivery changes the control design, not the underlying obligation.
What to do instead
Anchor on the activity, not the entity: identify who holds customer funds, who bears settlement risk, and which obligations (safeguarding, KYC/AML, consumer duty, outsourcing) attach. Then ask how the new architecture changes control evidence, and pick answers that preserve the obligation while adapting the mechanism.
Missing the settlement, liquidity, and counterparty mechanics of new payment rails and digital assets: assuming instant payment means instant finality, or ignoring prefunding, intraday liquidity, and reconciliation risk in API-driven flows.
Candidates reason from user experience (money 'arrives') rather than from settlement mechanics. Real-time rails often increase liquidity and fraud pressure while reducing the window for reversal, and digital asset settlement introduces custody and key-management risk that has no legacy analogue.
What to do instead
For each fintech scenario, trace the money: who debits, who credits, when is it final, who holds it in between, and what happens on failure. Prefer answers that address prefunding/liquidity buffers, reconciliation controls, custody and key management, and reversal/fraud handling before scaling volume.
Applying market-risk intuition (volatility, VaR, diversification) to credit and liquidity problems, for example concluding a portfolio is safe because positions are marked-to-market daily or because VaR is within limit.
Candidates over-learn VaR mechanics and treat it as a universal risk measure. VaR says nothing about tail severity, liquidity horizon, or credit migration, and daily marking does not eliminate default or funding risk. Exam items exploit this by offering a VaR-comfortable but liquidity-fragile answer.
What to do instead
Match the measure to the risk: use expected shortfall and stress testing for tail market risk, PD/LGD/EAD and migration analysis for credit, and cash-flow gap, liquidity coverage, and funding concentration for liquidity. Explicitly reject options that use a market-risk metric to justify a credit or funding decision.
Treating stress testing and scenario analysis as a compliance deliverable that confirms the business plan, using mild historical scenarios and reverse-engineering results to fit capital or risk appetite.
Candidates learn stress testing as a regulatory submission and default to 'run the historical crisis scenario and show we survive'. That misses the purpose: revealing vulnerabilities, informing risk appetite and contingency planning, and challenging assumptions including reverse stress tests to the point of failure.
What to do instead
Design scenarios that are severe but plausible, include reverse stress testing to identify breaking points, and connect outputs to limits, capital planning, and management actions. Choose answers where stress results change decisions; reject answers where the scenario is calibrated to pass.