Changed documents in credit cases and what should rerun
The commercial property loan is days from disbursement, and the file looks settled: the scorecard has run, a limit is recorded, the knock-out criteria are clear, the group exposure check is complete, and analysts have signed. Then the replacement balance sheet arrives. The first one was too old under policy, and the new document came back a week after the request, once those reviews were complete. You are looking at the revised figures alongside the completed record, with funds still unreleased. The approvals are there, but the basis for each one is now visible in two different versions of the borrower’s finances.
A changed document should rerun only dependent work
A replacement document should rerun only the work that depends on what changed. In our property loan design, a change to the document classifier’s confidence or the document period, both shown only for context in one review, set off a much wider cascade.
That cascade re-ran 16 automated tasks and re-opened 10 human reviews. The immediate cost is reviewer time spent looking again at information that did not need confirmation, followed by tasks repeating work downstream. A full reset can feel safer because the old document fed the completed checks, but it also repeats work that the changed value does not affect.
Review text can make a context value trigger rework
A review can re-open because its text displays a value that changed, even when that value is not what the reviewer must decide. In the document-type review, the recognised type mattered to the decision, but confidence and period were included for context. When either changed, the review re-opened, its answer counted as new, and more work followed.
A review can show figures for context. In Impact, a value checked only in a condition does not itself make a task repeat. Displaying it in review text can.
For each review that re-opens, decide whether the reviewer must confirm the changed value or only sees it for context. Keep the values that must be confirmed in the review text.
Remove only context values from review text
Remove a value from review text only when it is there for context and the reviewer does not need to confirm it. In our property loan design, we edited one document-type review to keep the recognised type and remove confidence and period. We left the other reviews unchanged, including the rating review, because its reviewer must reconsider a changed rating recommendation.
The targeted edit reduced the extra work from context-only values, but kept the reviews that needed to look again. Across the 20 inputs in the design, re-opened reviews summed to 87 instead of 107, and re-runs to 62 instead of 94.
| Changed input | Before | After |
|---|---|---|
| Document type | 16 and 10 | 16 and 10 |
| Classifier confidence | 16 and 10 | 0 and 0 |
| Period on the document | 16 and 10 | 0 and 0 |
| Rating recommendation | 3 and 7 | 3 and 7 |
The document-type review still re-opened when the document type changed, and the rating review still re-opened when the rating recommendation changed. Changes to confidence and period no longer caused re-runs or re-opens. Analyse again after each targeted edit, and confirm that reviews which must look again still do.
Demand fresh data when the decision is ready
Put freshness on the decision that needs the data, not on a schedule at the provider. In our engine test, the case waited fourteen days for documents with no extra provider call. When the documents arrived and the decision was otherwise ready, stale financials prompted one refresh, one new score and a decision based on the refreshed data.
| Moment | Provider calls | Scores | Decisions |
|---|---|---|---|
| Day 0, documents missing | 1 | 1 | 0 |
| Day 14, still waiting | 1 | 1 | 0 |
| Documents filed | 2 | 2 | 1 |
| Three days after deciding | 2 | 2 | 1 |
Refreshing on a timetable means paying the provider while a case waits for documents and no decision is being made. Request fresh data when the decision is ready instead, so the refresh happens once then.
On the deciding task, set “is fresher than” for the data it uses and the number of hours your policy allows. Add “is newer than” so the decision waits for a score computed from that data. If refreshed data comes back unchanged, the engine test kept the existing score because it was based on data just confirmed.
Before release, use the Test studio to check that tasks blocked on stale data show “waiting for fresh data”.
Check the loan case before release
Use this procedure for the loan case above, where the replacement balance sheet arrived after the reviews were complete and analysts had signed.
- Open Impact and change each input in turn, starting with documents. Record what re-runs and which reviews re-open.
- For each re-opened review, decide whether the reviewer must confirm the changed value or sees it only for context. Remove context-only values from that review’s text.
- Analyse again. Confirm that reviews which must look again still re-open.
- On the deciding task, set “is fresher than” for the data it uses and the hours your policy allows. Set “is newer than” so the decision waits for a score based on that data.
- Run the case in Test studio before release. Check that tasks waiting on stale data show “waiting for fresh data”.
Questions about case rework
What has to be redone when a document in a credit case changes?
It depends on what each task reads. Use Impact to see which automated tasks re-run and which human reviews re-open for that changed input.
Why does a review re-open when nothing it decides has changed?
Its text may display a changed value. If the reviewer sees that value only for context, remove it from the review text. Keep values the reviewer must confirm.
How often should a case refresh paid data before a decision?
Do not refresh it on a schedule just because time has passed. Put the freshness condition on the deciding task, using the hours your policy allows, so stale data prompts a refresh when that decision is otherwise ready.
What happens when refreshed data comes back unchanged?
In our engine test, the existing score was kept because it was based on data just confirmed. The decision used that score.
Should I take every value out of a review’s text?
No. Keep values the reviewer must confirm, such as the rating recommendation in our design. Remove only values shown for context when the reviewer does not need to reconsider them.
