IIBF Emerging Technologies common mistakes
IIBF Emerging Technologies · Understand the traps and how to avoid them.
Treating 'digital transformation' as a synonym for 'buying new technology', and answering questions about organisational change, process redesign, or customer-journey re-engineering with a technology-product answer (e.g., picking 'implement a core banking system' where the question asks about the primary driver of transformation success).
Marketing material and vendor narratives dominate the candidate's exposure to the topic, so transformation gets mentally filed as an IT procurement exercise. The strategic, people and governance dimensions that the syllabus emphasises are never rehearsed.
What to do instead
Before answering, classify the stem: is it asking about strategy/governance, process, people/culture, or technology? Build a one-page map of the transformation lifecycle (vision and business case, process re-engineering, data and API layers, change management, benefits realisation) and practise tagging each practice question to one of those layers. When two options both mention technology, prefer the one that also addresses process or capability building.
Confusing the regulatory posture of banks with that of NBFCs and fintech partners - for example assuming an NBFC must follow every bank-specific prudential norm, or assuming a fintech lending partner bears the same compliance obligations as the regulated entity on whose balance sheet the loan sits.
Candidates study one institution type deeply and then over-generalise. The distinctions (permitted activities, capital and exposure norms, outsourcing and co-lending responsibilities, who is the regulated entity in a partnership) are scattered across circulars rather than consolidated in one chapter.
What to do instead
Maintain a three-column comparison table - commercial bank, NBFC, fintech/LSP - with rows for licensing, capital, permitted digital activities, outsourcing accountability, grievance redressal and reporting. For any partnership scenario question, first identify the regulated entity, then ask who owns the customer relationship and who bears the risk.
Answering AI/ML questions by pattern-matching the label rather than the learning problem - e.g., choosing 'supervised learning' for every predictive question, or calling a credit-scoring model 'unsupervised' because it segments customers, or mixing up classification and regression when the target variable is continuous (loss given default, exposure amount).
The candidate memorises buzzwords from news articles instead of the underlying formalism (labelled vs unlabelled data, discrete vs continuous target, train/validation/test split). Exam stems deliberately describe the business problem without naming the technique.
What to do instead
Drill a decision tree: is the target labelled? If yes, is it discrete (classification) or continuous (regression)? If no labels, is the goal grouping (clustering) or dimensionality reduction? Work through ten banking use cases - fraud detection, churn, collections propensity, document classification, AML alert triage - and assign technique, target type and evaluation metric to each.
Judging model quality by accuracy alone and ignoring class imbalance, or failing to distinguish model performance metrics from business outcome metrics - e.g., picking 'accuracy' as the right measure for a rare-event fraud or default model, or confusing precision with recall when the cost of a false negative is high.
Accuracy is the only metric most candidates have seen in introductory material. Rare-event problems (fraud, defaults, AML) are precisely where accuracy is misleading, and the exam tests whether the candidate understands the trade-off between false positives (customer friction) and false negatives (loss).
What to do instead
Learn the confusion matrix cold, then memorise the banking mapping: recall/sensitivity matters when missing a bad case is costly (fraud, default); precision matters when flagging a good customer is costly (blocking a genuine transaction). Practise explaining why a 99%-accurate model on 1%-fraud data can still be useless, and know AUC-ROC, precision-recall curves and KS statistic as alternatives.
Treating model governance as a one-time validation event - answering that a model is 'approved at deployment' and ignoring ongoing monitoring, drift detection, periodic revalidation, explainability and human override, or failing to recognise that an outsourced or vendor model still requires the regulated entity's own validation.
The candidate thinks of model risk as a software release gate rather than a lifecycle. Regulatory expectations around model risk management, explainability of credit decisions and accountability for outsourced models are less publicised than the modelling techniques themselves.
What to do instead
Memorise the model lifecycle as a loop: data quality, development, independent validation, approval, deployment, ongoing monitoring (performance, stability, drift), periodic review, retirement. For every governance question ask 'who is accountable and what is the evidence?' - and remember that outsourcing the model never outsources the accountability.
Confusing authentication with authorisation, or identification with authentication - e.g., selecting 'two-factor authentication' as the control that limits what a logged-in user can access, or treating a password plus OTP as authorisation.
Everyday usage blurs these terms, and the candidate has never had to separate them. Exam questions test the distinction precisely because control design depends on it.
What to do instead
Fix the definitions with a one-line mnemonic: identification = who claims to be; authentication = proving it; authorisation = what they may do; accounting = recording what they did. Then map controls to each: passwords/tokens/biometrics to authentication, role-based access control and least privilege to authorisation, logs and audit trails to accounting. Re-sort a list of twenty controls into these four buckets until it is automatic.
Treating cyber security as purely a technology problem and omitting governance, people and third-party dimensions - e.g., answering a question about the most effective defence against phishing with a firewall or antivirus product rather than awareness training, or ignoring vendor/third-party risk in a supply-chain scenario.
Candidates default to technical controls they can name. The syllabus treats security as a risk-management discipline spanning governance, culture, incident response and vendor oversight, and many questions are framed to reward the non-technical control.
What to do instead
Build a layered defence model - governance and policy, identity and access, data protection, network and endpoint, monitoring and detection, incident response and recovery, people awareness, third-party oversight - and for each scenario ask which layer the stem is probing. Note that social-engineering questions almost always reward awareness and process controls over products.
Mixing up the roles of the three lines of defence, or collapsing IT risk into a single owner - e.g., stating that the internal audit function 'owns' operational risk, or that the IT department is the second line for technology risk.
The three-lines model is described abstractly in study material and candidates never apply it to concrete technology scenarios. The distinction between owning risk (first line), overseeing and setting frameworks (second line) and providing independent assurance (third line) is easy to state and easy to muddle under exam pressure.
What to do instead
Anchor each line with one verb: first line owns and manages risk; second line sets framework, monitors and challenges; third line provides independent assurance. Then rehearse five technology scenarios (cloud migration, outsourcing, incident management, access control, change management) and assign each activity to a line. Audit never owns a risk; it assures on it.
Confusing a data breach notification duty with a general privacy obligation, or assuming consent is the only lawful basis - e.g., answering that all personal data processing requires consent, or that breach reporting is optional if the data was encrypted.
Candidates absorb headlines about consent and breach fines without the statutory structure. The DPDP framework distinguishes consent from certain legitimate uses, and imposes specific, time-bound breach notification to the regulator and affected individuals, with penalties tied to the nature of the failure.
What to do instead
Learn the Act as a structure, not a list of facts: definitions (data principal, data fiduciary, data processor, personal data, significant data fiduciary), grounds for processing, notice and consent requirements, data principal rights, obligations of fiduciaries, breach notification, and the penalty schedule. For any scenario, ask: who is the fiduciary, what is the ground for processing, was notice given, and does the incident trigger notification?
Answering digital-lending questions by focusing on the app or the algorithm while ignoring the regulatory expectations around the customer journey - e.g., missing that the lender of record must be disclosed, that consent and data sourcing must be documented, that recovery practices are regulated, or that grievance redressal must be available through the regulated entity.
Candidates experience digital lending as a user interface and therefore analyse it as a product question. The regulatory concerns are about transparency, who the counterparty is, data handling and conduct, which are less visible from the outside.
What to do instead
Map the digital-lending value chain end to end - sourcing and onboarding, KYC, underwriting and data used, disbursement and escrow, servicing, collections and recovery, grievance redressal - and for each stage note the conduct and disclosure expectation. In any scenario question, first identify the lender of record and the regulated entity, then check disclosure, consent and data handling.