Insights from practice · 2026
54 developed articles on banking, data, IT, testing and risk. Each combines a documented real case, practical analysis, recommendations and source links.
Editorial series dates are spaced two days apart, ending on 26 October 2026. All texts in this edition were reviewed and expanded on 28 October 2026.
01↗The TSB case illustrates the difference between finishing a technical task and keeping banking services available. My proposed approach connects data checks, service testing and release decisions.
Read article →
02↗Repeated supervisory action involving Citi raises a practical question: how do we move from completed project tasks to evidence that a data risk has been sustainably reduced?
Read article →
03↗When conditions change within hours, correct information arriving late is not enough. The Silicon Valley Bank case helps separate risk assumptions, data evidence and the ability to act.
Read article →
04↗The 2016 Bangladesh Bank cyber theft offers a way to examine permissions, independent checks and responses to unusual payments. My proposed analysis looks at the complete process rather than one technical barrier.
Read article →
05↗A current overview connects supervisory developments with practical questions for data analysis, process reviews and clear findings.
Read article →
06↗The ECB’s revised approach to material model changes highlights independent controls, documentation and implementation readiness.
Read article →
07↗Reading the CNB’s October survey without treating aggregate trends as findings about an individual bank.
Read article →
08↗Strong sector-wide resilience and close scrutiny of individual processes complement each other. How should the results be read?
Read article →
09↗Rather than calculate one crisis outcome, identify a scenario that would materially weaken the bank and explain the transmission.
Read article →
10↗A healthy current portfolio can conceal weaknesses that emerge later. How should new lending be reviewed?
Read article →
11↗Why standardised calculations still need strong data when models are used, and how to distinguish methodological effects from risk changes.
Read article →
12↗Changes to supervisory publications bring data governance, scope and cross-system consistency into focus.
Read article →
13↗Move beyond sustainability labels to borrower-level financial effects and evidence quality.
Read article →
14↗Connect individual findings with the wider risk-management picture without overinterpreting one indicator.
Read article →
15↗A matching total is a starting point. Trust also depends on understanding what the numbers cover, where they come from and how they were produced.
Read article →
16↗A discrepancy visible in a report may have originated several steps earlier. Breaking down the data journey makes investigation more focused.
Read article →
17↗A precise discrepancy, supporting evidence and a clear next step turn an observation into an actionable task.
Read article →
18↗Credit risk is an area I want to develop in, building on my background in data and process analysis, validation and documentation.
Read article →
19↗Connecting the review objective, requested evidence and verifiable steps.
Read article →
20↗Distinguishing targeted investigation from estimating how often a problem occurs.
Read article →
21↗Reviewing income, obligations and the assumptions behind a lending decision.
Read article →
22↗Decision traceability matters even while a loan is performing.
Read article →
23↗From a deteriorating indicator to ownership and follow-up.
Read article →
24↗Why the number of loans alone does not describe diversification.
Read article →
25↗Valuation, freshness and traceability differ from repayment capacity.
Read article →
26↗A clear scenario helps identify portfolio vulnerabilities.
Read article →
27↗Thinking through the evidence behind changes to loan terms.
Read article →
28↗What to examine when model output differs from the final assessment.
Read article →
29↗Distinguishing execution, independent challenge and assurance.
Read article →
30↗What simple data checks can reveal, and what requires investigation.
Read article →
31↗Source versions, analytical steps and limits belong together.
Read article →
32↗Using discussion to supplement evidence and resolve inconsistencies.
Read article →
33↗Connecting the assessment criterion, observed condition and risk.
Read article →
34↗Checking both implementation and operation of a change.
Read article →
35↗A practical look at using generative AI for test design, defect analysis and documentation—without blindly trusting automatically generated answers.
Read article →
36↗Non-deterministic outputs require a different verification strategy from a traditional function with one exact expected result.
Read article →
37↗Automation delivers the greatest value when it protects critical journeys and removes repeated manual work.
Read article →
38↗A small change in data structure can break an integrated process even when every team considers its own service healthy.
Read article →
39↗Incorrect results can originate during import, transformation, segmentation or export. Checking only the final report is not enough.
Read article →
40↗Realistic data matters for testing, but copying production information is not automatically the right solution.
Read article →
41↗Quality is not created only during a test phase. It starts when requirements are shaped and continues through observation in production.
Read article →
42↗Logs, metrics and traces are not only operational tools. They also show whether a system can explain its own failures clearly.
Read article →
43↗An accessible product is clearer, easier to operate and more robust for a much wider range of users.
Read article →
44↗A test that passes and fails without a product change gradually stops being taken seriously.
Read article →
45↗When everything cannot be tested, priority should reflect impact, likelihood and the chance of detecting failure in time.
Read article →
46↗A quick fix restores service. Understanding the cause reduces the chance that the problem returns.
Read article →
47↗The number of tests or defects alone does not show whether the product is safer or the team more effective.
Read article →
48↗An ambiguity discovered during refinement is cheaper than a defect discovered immediately before release.
Read article →
49↗Exploratory testing is not random clicking. A well-designed charter gives the investigation a purpose while preserving room for discovery.
Read article →
50↗Passing tests is not enough before deployment. The team needs a shared view of change, risk and operational preparedness.
Read article →
51↗It is impossible to manually verify every combination of device, browser, resolution and operating system.
Read article →
52↗Performance is not only the speed of one screen. It includes response time, throughput, stability and behaviour under peaks.
Read article →
53↗A strong defect report enables another person to understand, reproduce and assess the impact of the problem.
Read article →
54↗Improvement is not a long list of ideas. It is choosing one concrete change, testing it and returning to the result.
Read article →