Automated adverse action notices are not a new idea; most consumer lenders already generate declines from a template. What is usually not automated is everything that makes a notice lawful: the clock measured from the completed application, the trace from each printed reason back to the factor or rule that produced it, the check that a code map still matches the model version that decided, and the evidence that any of it happened. ECOA itself contemplates the volume approach — a creditor satisfies the statement-of-reasons duty by "providing statements of reasons in writing as a matter of course to applicants against whom adverse action is taken" — but immediately adds the test that no volume approach passes by itself: "A statement of reasons meets the requirements of this section only if it contains the specific reasons for the adverse action taken" (15 U.S.C. 1691(d)). Botminds' Adverse Action Notice Automation automates the checks, the clocks and the drafting, and leaves the signature, the map changes and the decision to correct with the people who own them.
The examples on this page come from the working prototype running on sample lending data: a fictional lender, fictional applicants and fictional products. The statute, the regulation and its interpretations are linked where they appear.
What can actually be automated in an adverse action programme
Six things, and they divide cleanly by whether the answer is determined by evidence or by judgement. Reading the decision as it is made, including the completed-application date, is determined. Ranking the factors and failed rules and selecting the principal reasons is determined once the policy for selection is set. Comparing the words for each reason code against the model documentation for the version that decided is determined — it is a string against a document. Checking the FCRA block against what the bureau supplied is determined. Writing the letter from the approved template for a product, action and state is determined. Keeping the clocks, assembling the batch, confirming delivery and retaining the material for 25 months is determined.
What is left is small and it is the whole of the risk: whether this notice should go, whether a reason's new wording is right, and whether letters already sent should be corrected. Those are three decisions a year's worth of mechanical accuracy does not qualify a machine to make.
Six jobs, each with a limit written into it
Agent
Decision readerReads each decision as it is made: product, action, model version, score, cutoff, failed policy rules, and the completed-application date that starts the clock.
Never: changes a decision, or starts the clock at a referral or decision date
Agent
Reason tracerRanks the factors and failed rules by their effect on this decision and picks up to four principal reasons, each traced to its factor.
Never: uses a factor the decision did not score
Agent
Reason-map checkerCompares the words for every reason code against the model documentation for the version that decided, and holds any notice whose words disagree.
Never: changes the map — the model owner and the compliance officer approve
Agent
Bureau disclosure checkerChecks the FCRA content where a report was used: score, range, date, key factors, the agency’s contact, the free report and the dispute right.
Never: omits inquiries where they are a key factor
Agent
Notice writerWrites each letter from the approved template for its product, action and state, with the ECOA statement, the federal agency and any state statement.
Never: sends a letter, or uses an unapproved template
Agent
Clock keeperKeeps every 30- and 90-day clock, builds the daily batch, confirms delivery, re-sends returned mail and retains the material.
Never: lets a notice pass its due date silently
A person decides
The compliance analystApproves each notice and signs the batch, with the meaning of the signature and the time recorded.
Never: has a letter sent on their behalf without it
The checks worth running on every notice
The useful question for a buyer is not how many checks a product claims but what each one is checked against. A check against the template tells you the production line ran. A check against the decision tells you the letter is true. In the prototype's daily batch, nine run on every notice, and the counts beside them are the evidence rather than the claim.
The nine checks on every notice in one 1,785-letter batch
- Every reason traced to a factor or rule
1,785 of 1,785. Traced from the decision, not read forward from the code map.
- At most four principal reasons
The lender’s own setting, ranked by their effect on this decision.
- ECOA statement and federal agency
The Appendix A entry for this charter — here, the Bureau.
- Inside the legal clock
Earliest due Tue 13 Oct; nothing in the batch is past its clock.
- E-delivery only with E-SIGN consent
1,142 consents on file, matched per applicant rather than per channel.
- Map version matches the model version
All four models in the batch, each against the documentation for the version that decided.
- Credit score, key factors, bureau contact
1,785 used a report; the score block checked against what the bureau supplied.
- State statements
Ohio, 41 in New York, 12 in California — per product and state, not per template family.
- Plain words
Each reason at reading grade 8 or lower, the lender’s set level.
Two of the nine are worth singling out for anyone comparing products. The map-version check is the one that catches the failure no content review can see — a reason code whose meaning changed with a new model — and it is the check most products do not have, because it requires reading model documentation rather than a template. And the E-SIGN consent check belongs per applicant: a batch that routes by channel preference rather than by consent on file will deliver some notices electronically to applicants who never consented, which is a missing disclosure rather than a delivery error.
What still needs a person, and why that is the point
Three decisions, and each one has a reason for staying human that survives any improvement in the machine.
Releasing the notice. A signature means something only if the signer could have withheld it. In the prototype the analyst approves each notice and signs the batch, and what is recorded is not just the act but the meaning of the signature and the time — which is what makes it evidence later.
Changing what a reason code means. New words for a code need someone who knows what the model scored and someone who knows what the regulation requires, and those competences are rarely in one person. The prototype requires both the model owner and the compliance officer, with both approvals recorded before any letter uses the new version.
Deciding whether corrected notices go. A corrected letter reaches an applicant who has usually moved on, and weighing that against the value of the correction is a judgement about people, not about data. It belongs to the compliance officer, as the guide on findings and remediation sets out.
The same programme, from each seat that carries it
Today
Owns roughly 14,300 notices a month, each worded from a code map kept by hand.
With agents
Opens on the letter with each reason’s proof beside it, rewrites a vague reason from the factor in one action, and signs the batch.
Still theirs: approving every notice and signing every batch
Today
“If a reason is wrong on one letter, it’s wrong on every letter that model wrote” — with no way to enumerate them.
With agents
Sees every letter that carried the wrong words, with a corrected notice drafted for each.
Still theirs: deciding whether corrected notices go
Today
“When we change a code, I need to know every place it lands.”
With agents
Sees the code’s meaning in his own model documentation beside the words on the letter, with the affected counts in front of him.
Still theirs: approving a map change, jointly with compliance
Today
“We decide on day 24 and compliance has six days to mail it.”
With agents
Every notice is on its clock from the completed application, and an override with no reason recorded surfaces with days left.
Still theirs: the credit decision itself
Today
“Tell me by four what goes in the mail.”
With agents
Gets the batch by product and channel, e-delivery only where consent is on file, and returned mail re-sent to the address on the report.
Still theirs: the relationship with the print and e-delivery vendors
How to measure whether it works: five numbers
Most adverse action programmes are reported on one number — notices sent — which measures the mailroom. Five numbers measure the obligation, and a programme that cannot produce the third of them has automated the wrong half.
Five measures, and who should own each
Median days to notice
median(notice date − completed application date)
Measured from the completed application, which is where the regulation starts the clock, rather than from the credit decision.
Operations
Notices past their clock
count(sent date > due date)
A count, not a rate. The target is zero, and any number above it is a violation per letter.
Compliance officer
Reason accuracy on a traced sample
accurate ÷ sampled, traced from the decision
The only measure that tests whether the words are true. Traced independently of the code map, because the map is the artefact under suspicion.
Compliance testing
Held-notice rate
held ÷ drafted, by reason for holding
A rising hold rate is the control working, not failing. A hold rate of zero on a changing model book means the check is not running.
Compliance analyst
Corrected notices
count(letters re-issued) and the population each came from
Reported with the population scanned, so a finding of three in a sample is never reported as three letters.
Compliance officer
Ask a vendor for the third and the fifth. The first two come free with any workflow tool; a held-notice rate implies at least one real check; but reason accuracy on a traced sample can only be produced by a system that holds the decision, the factors and the letter together, and the ability to enumerate a population of affected letters can only be produced by one that records findings against a code and a model version.
The same programme, run by hand and with the mechanical part automated
By hand: A report, or a spreadsheet, keyed on the decision date because that is the field the origination system holds.
With the mechanical part automated: On every open file, keyed on the completed-application date, sorted by days left rather than by stage.
By hand: A code map in a spreadsheet, maintained by whoever last had to.
With the mechanical part automated: Traced from the factors and failed rules the decision recorded, then checked against the model documentation for that version.
By hand: Nothing happens, which is the failure. The map keeps printing yesterday’s sentences.
With the mechanical part automated: Every notice on an affected code is held, the sent letters are counted, and new words go to two approvers.
By hand: A monthly sample read against the map and the template.
With the mechanical part automated: A monthly sample re-traced from the decision, with findings keyed to code and model version.
By hand: A file reconstruction, days of it, and sometimes an answer.
With the mechanical part automated: One view: inputs, model version, reasons with the factor behind each, the letter and its delivery.
By hand: Assembles, words, checks, fixes, chases, and signs.
With the mechanical part automated: Reviews, decides and signs.
What it needs from your systems
Six feeds, and the hard requirement is in the second and third rather than in the first. Any origination system can hand over a decision; few hand over the completed-application date as a distinct field, and almost none hand over the model documentation that says what a reason code meant in the version that decided. A programme without that third feed can check a letter against a template and nothing else.
What the work needs from each system, and why
| System | What it supplies | Why that particular field |
|---|---|---|
| Loan origination system | The decision, the action taken, and the completed-application date | The regulation starts the 30 days at the completed application; a decision date produces letters that are late before anyone looks. |
| Decision models and policy rules | Each decision’s reason codes, factor values and failed rules | Comment 9(b)(2)-4 requires the reasons to relate only to the factors actually scored, which cannot be checked from the codes alone. |
| Model inventory | Model documentation by version, and the reason-code maps | The only reference against which a code’s wording can be shown to be true for the version that decided. |
| Credit bureau reports | The score, its range, its creation date, its supplier and the key factors used | The FCRA score block is per applicant and per score, and its creation date drifts from the letter date on any file held in review. |
| Notice templates | Approved letters by product, action and state, with versions | A template is a control; a letter has to be tied to the version that produced it. |
| E-delivery and print vendor | The batch out, delivery confirmations, returned mail back, and consent status | E-SIGN consent is a precondition of the disclosure, and a returned letter is an undelivered notice until it is re-sent. |
| Applicant records | Which applicant is the primary one, where one is readily apparent | Section 1002.9(f): on a joint application notice need go to only one applicant, but it must go to the primary where one is readily apparent. |
One more requirement is contractual rather than technical. Where a third party produces or sends the notice, the Official Interpretations give the lender a conditional shelter: a creditor "is not liable for an act or omission of the third party that constitutes a violation of the regulation if the creditor accurately and in a timely manner provided the third party with the information necessary for the notification and maintains reasonable procedures adapted to prevent such violations" (comment 9(g)-3). Both limbs have to hold, and the second is a procedure the lender must be able to show. A print vendor contract is not one.
How to pilot it honestly on your own declines
A pilot that proves nothing is easy to run: take last month's letters, re-generate them, observe that they match. What that tests is reproducibility. An honest pilot tests the three things a buyer actually needs to know, and all three can be run on a sample of real declines without changing a single live letter.
First, reason accuracy against the decision, not against the old letter. Take a sample of declines across every product and decision type, have the system produce reasons from the factors and failed rules recorded at the time, and compare those to the words the applicant received. Disagreements are the finding, and the interesting ones are where the old letter was wrong.
Second, the clocks. Recompute the completed-application date for the same sample from the fields the origination system actually holds, and compare the resulting due dates to the dates on which notices went. A pilot that finds no late notices and also finds that the clock was being measured from the decision has found something important.
Third, the hold. Introduce a known mismatch — a code whose documented meaning differs from the letter wording — and confirm the notice is held rather than sent with a warning. A check that cannot stop a letter is not a check. Regulation B's own definition of a creditor's "procedures" is the actual practices followed rather than the stated ones (comment 2(f)-2), and a pilot is the cheapest place to find out which you have.
Build, buy, or keep the spreadsheet
The honest version of this comparison turns on one thing: whether anyone will own the reason-code map as a control. The letter generation is not hard to build, and the clocks are not hard to build. The map check requires a durable connection between model documentation and letter wording, a hold that stops a batch, and two named approvers — and that is a governance artefact as much as a piece of software.
Three ways to run it, and what each one really costs
| Approach | What it handles well | Where it fails, and at what scale |
|---|---|---|
| Keep the spreadsheet | Low volume, one product, one model, a stable code map and an experienced analyst. | The day the model version changes. Fails silently and retrospectively, across every letter the changed code touched. |
| Build it | Letter generation, the clocks, the batch — all tractable, and you own the data model. | The map check and the trace, which need model documentation ingested and versioned; and the second product, which doubles the surface. |
| Buy it | The checks, the clocks, the trace and the population scan, with the governance already shaped. | Anything your decision engine cannot hand over. A product cannot trace a reason to a factor your systems do not record. |
Where Adverse Action Notice Automation earns its place, and where it does not
It earns its place on the checks and the clocks. In the prototype's sample data a 16:00 batch of 1,785 notices across four products passes nine checks on every letter, with 1,142 going by e-delivery and 643 to the print vendor, and nothing in the batch past its clock. The analyst releases it — on the sample day at 09:19, ahead of the cut-off — and the signature, its meaning and its time go on the activity trail with every agent step beside it.
Adverse Action Notice Automation: one day's batch, with the nine checks and their counts
It does not decide anything about credit. The agents never change a decision, never change the reason-code map, and never send a letter. It does not replace model governance: whether a machine learning scorecard can produce a lawful statement of reasons at all is a separate question, taken up in the guide on explainable AI credit scoring. It does not fix a decision engine that does not record which factors it scored — no product can trace a reason to a factor your systems never kept. And it does not make the judgement calls: a corrected notice goes because a compliance officer says so.
Adverse Action Notice Automation: signed, released, and on the trail
The series this page closes works through the rules behind each of those checks: what the letter must say, when the clock starts and how a model's codes become sentences. To see the batch, the checks and the trail on your own declines, start from Adverse Action Notice Automation.
Questions people ask
Can adverse action notices be automated?
The production of them, yes — ECOA expressly contemplates a creditor "providing statements of reasons in writing as a matter of course", and the clocks, the content checks, the batch and the retention are all mechanical work. The judgement is not: releasing a notice, approving new wording for a reason code, and deciding whether letters already sent should be corrected are decisions that should stay with named people, because each one is a statement the lender is making about an applicant.
What checks should run before a notice goes out?
At minimum: every reason traced to a factor or failed rule the decision actually recorded; the reason count within the lender's limit; the ECOA statement and the correct supervising agency for the charter; the notice inside its 30- or 90-day clock; electronic delivery only where E-SIGN consent is on file; the code map matching the model version that decided; the FCRA score block matching what the bureau supplied; any state statements for the product and state; and the reasons at the lender's reading level. The important property is what each is checked against — a check against the template proves only that the template ran.
How do you measure whether notice automation works?
Five numbers: median days from the completed application to the notice; the count of notices sent past their due date, which should be zero; reason accuracy on a sample re-traced from the decision rather than from the code map; the held-notice rate with the reason for each hold; and corrected notices, reported with the population each came from. The third is the one that distinguishes a notice programme from a mail programme, and the one to ask any vendor to demonstrate.
What data does adverse action automation need from a loan origination system?
The decision and the action taken, the model version and score, the failed policy rules with their values, and — the field most systems do not expose cleanly — the completed-application date, because that is where Regulation B starts the 30 days. On joint applications it also needs to know which applicant is primary, since section 1002.9(f) requires the notice to go to the primary applicant where one is readily apparent. Without the factor values behind the codes, no system can check that a reason describes what was scored.
What still needs a person?
Three things. A person approves and signs each release, because a signature that could not have been withheld is not evidence of anything. A model owner and a compliance officer jointly approve any change to what a reason code means, because that change needs both competences. And a compliance officer decides whether corrected notices go, because reaching an applicant again about a decision that has not changed is a judgement about people rather than about data.
How long does it take to go live?
The honest answer depends almost entirely on one thing: whether your decision engine already records the factor values and failed rules behind each decision, and whether your model inventory holds documentation by version. Where both exist, the work is mapping feeds and agreeing settings — clocks, reason counts, reading level, approvers, retention. Where they do not, that gap is the project, and no notice product shortens it. Start with a sample of your own declines, which will show you which case you are in within a day.