These analytical notes explore a field I want to develop in. The examples are hypothetical and do not describe inspections I have carried out.
Define the scope first
Before collecting data, identify the process and period under review. “Does monitoring work?” is too broad. A more useful question asks whether deterioration in a selected segment is identified promptly and followed by a decision from the responsible person.
Match evidence to the question
A review can connect the methodology, monitored cases, alert timestamps and records of subsequent action. Policy describes the expected process; records show what actually happened. Interviews can explain differences, but do not replace documentary evidence.
Hypothetical example
A bank says alerts are handled within five working days. I would compare creation, assignment and closure dates for selected cases, including waiting states and exceptions. The result would concern the reviewed sample. A portfolio-wide conclusion would require consideration of how that sample was selected.
Building a working plan
A well-prepared review connects several views of one process. Policy describes the intended approach, data reveals its scale, and case files show what happened. Differences between these layers create questions for further investigation. I would map the question, the evidence needed and the basis for deciding whether the conclusion is sufficiently supported.
The plan should leave room for surprises. A supplied list may differ from the requested scope, or an employee may describe an undocumented practice. Before broadening every information request, determine whether the difference concerns terminology, missing records or an actual process deviation.
Interpreting the case timeline
Testing a five-day deadline requires more than subtracting two dates. Understand the trigger, working days, pauses and changes in severity. A case closed on time may remain unresolved in substance; another may stay open while additional evidence is properly obtained. Timing analysis should inform assessment rather than replace it.
Preparation should produce feasible tests and open questions. This helps team members work to a common scope and exchange relevant context. The link to process analysis is clear: break a complex problem into manageable steps while keeping sight of why those steps matter.
A real example: the 2014 European bank assessment
On 26 October 2014 the ECB published its comprehensive assessment of 130 large euro-area banks. It combined an asset quality review with stress assessment and identified capital shortfalls at some institutions. This was a large European exercise, not a routine inspection of a Czech bank. Its published results illustrate the importance of common reference dates, clear methodology and comparable evidence populations.
My analytical starting point is the difference between forming a question and collecting files. Asking for every available report can produce a large volume of material with inconsistent meanings. Defining the assertion under examination and the evidence that could support or challenge it allows more focused requests. That is not an invitation to seek only the expected weakness; the plan should remain open to alternative explanations and evidence that changes the initial view.
Hypothetical example: exceptions in credit approval
Suppose the assertion is that a bank properly approves exceptions to its lending rules. My first request would not be limited to a list of recorded approvals. I would need the exception definition, recording rule, authority register and circumstances in which a non-standard decision is permitted. Otherwise the exercise may inspect visible records while overlooking cases that should have been recorded but were not.
For a hypothetical population of 5,000 approved applications I would first define the period and sampling unit: application, customer, contract or individual decision. A customer can hold several contracts, and an application can have multiple revisions. Without this distinction the number of exceptions may be difficult to interpret. The sample size would follow the purpose and risk; the illustrative population figure is not a statistical sampling methodology.
Preparing the evidence before a visit
I would draw a working process map from application receipt through assessment and approval to subsequent monitoring. Each step would identify a responsible role, system and expected record. The map supports interview planning and checks dependencies between activities. An inability to identify where decisive information originates is an initial open question to clarify, rather than automatically a final inspection finding.
I would specify datasets in a way that allows the same request to be fulfilled consistently again. That includes the reference date, fields, code meanings and treatment of excluded records. A delivery record would retain row counts and versions. Later differences could then be investigated against identifiable files, instead of relying on an unnamed attachment downloaded from an email and modified without a trace.
A sample should not merely be convenient
I would select cases for documented reasons: high exposure, unusual approval, rating changes, decisions near a reporting boundary or missing information. A targeted sample can reveal how a risk mechanism operates, but does not automatically support estimating its frequency across the portfolio. If a statistical estimate is required, the sample design and specialist interpretation need to support that purpose explicitly.
The plan would also contain ordinary cases. They help establish normal operation and distinguish a systematic weakness from exceptional handling of a particular situation. If the same issue appears in both targeted and ordinary cases, that may justify expanding the investigation. I would still distinguish conclusions based on individual files from conclusions supported by analysis of the entire data population.
Readiness also means access and safe handling
I would check staff availability, system permissions and secure document-sharing arrangements. Sensitive information should not be copied into an uncontrolled working folder merely to accelerate an inspection. Agreed evidence handling protects both the institution and the reliability of the result. Time saved through preparation is then available for verification rather than repeatedly arranging access or searching for the person able to explain a particular extract.
There should also be a route for changes in scope. An unexpected concentration or unexplained discrepancy may justify additional work, but the reason should be recorded and agreed through the appropriate process. A clear initial plan is useful precisely because it makes a justified departure visible. Quietly expanding requests without revisiting the purpose can overwhelm the team and leave the original question unanswered.
I would prepare an evidence register linking each question to the files, interviews and calculations used. A single source may support several questions, while one conclusion may require several independent sources. This arrangement reduces duplicate requests and exposes unsupported assumptions early. It also helps a reviewer understand why a finding is narrower or broader than the initial question.
Summary and recommendations
Begin with an inspection question, define the period and population, and identify the evidence needed. Prepare a process map, data definitions, transparent selection reasons and secure handling arrangements. European examples provide context, while the actual procedure must follow the relevant mandate and methodology. My contribution would be connecting requirements, data and documents so that time on site leads to a conclusion that can be explained, challenged and reproduced.