How to audit an automated adverse action workflow

The target keyword for this guide is automated adverse action workflow.

Adverse action is one of the highest leverage places to improve background screening operations, but it is also one of the worst places to hide policy inside a black box. The workflow touches reports, notices, attachments, timing, disputes, final decisions, and records that teams may need to explain later.

For consumer reporting agencies, the goal is not simply to send notices faster. The goal is to make the process consistent, reviewable, and easy to reconstruct when an employer, candidate, auditor, or internal compliance lead asks what happened.

This audit checklist is for CRA operators evaluating whether an adverse action workflow is ready for automation, or whether an existing automated workflow has enough controls to trust in production.

Start with the policy boundary

Before reviewing screens or integrations, write down which decisions belong to automation and which decisions belong to people. Automation can prepare packets, track status, capture delivery evidence, calculate waiting windows, and route cases. It should not silently decide that final adverse action is allowed when the policy path still requires human review.

A useful boundary statement looks like this:

1. The automation may identify cases that are eligible for pre adverse action preparation.
2. The automation may assemble the report copy, rights summary, employer notice template, and case metadata.
3. The automation may send or queue the pre adverse notice only after the configured approval step.
4. The automation may track the response window and candidate activity.
5. The automation may prepare the final action step, but final release requires the configured review condition.

That boundary should be visible to operations and compliance. If it only exists in a prompt or script, it is not enough.

Komos treats this as a controlled workflow problem. The broader CRA map is on the background screening automation hub, and the specific use case is FCRA adverse action automation.

Map the adverse action state machine

Adverse action workflows fail when the case state is informal. A candidate cannot be both waiting for a response and ready for final action. A notice cannot be both drafted and delivered. A dispute cannot be both open and ignored by the waiting period logic.

At minimum, define states for:

1. Case flagged for review.
2. Pre adverse packet drafted.
3. Reviewer approval required.
4. Pre adverse notice delivered.
5. Waiting period active.
6. Candidate response received.
7. Dispute or reinvestigation path active.
8. Cleared with no final action.
9. Final adverse packet drafted.
10. Final notice delivered.
11. Closed with evidence retained.

Each state needs an owner, allowed next states, and a record of who or what moved the case. This gives the automation guardrails and gives the team a useful audit trail.

Check the packet before delivery

The pre adverse packet should be treated as a controlled artifact. Before anything is sent, the workflow should verify that the packet has the right documents, the right candidate, the right report, and the right template version.

The packet audit should include:

1. Candidate name and case ID.
2. Employer or end user identity.
3. Report version or report section used for the decision.
4. Notice template version.
5. Required attachments.
6. Delivery channel.
7. Reviewer or policy approval.
8. Timestamp for the approval and send event.

Official FTC guidance for employers describes notice requirements before and after adverse action when an employment decision is based on a consumer report. The CFPB also describes worker rights around consumer reports, disputes, adverse action notices, and permissible purposes. The links are useful references for internal process owners:

1. FTC guidance on using consumer reports for employment decisions.
2. FTC guidance on background checks for employers.
3. CFPB circular on background dossiers and employment decisions.

This post is operational guidance, not legal advice. Your counsel and compliance team own the policy. The automation should make their policy easier to enforce and inspect.

Preserve delivery and waiting evidence

A workflow that sends a notice but cannot prove delivery status is incomplete. The same is true for a workflow that records a waiting period without preserving how the window was calculated.

For every pre adverse notice, store:

1. Delivery attempt timestamp.
2. Delivery provider or portal used.
3. Recipient address or destination identifier.
4. Delivery result.
5. Bounce, failure, or retry events.
6. Waiting period start timestamp.
7. Waiting period end timestamp.
8. Any response, dispute, or candidate communication.

This is where browser automation and API automation often need to work together. Some teams send through an API. Others send through an ATS, screening platform, employer portal, or email provider. Some need to download receipts or screenshots from a portal. The workflow should capture that evidence wherever it lives.

Route disputes as first class work

A candidate response is not an edge case. In an adverse action workflow, it is one of the core paths. If the candidate disputes information, asks for a copy, or provides context, the automation should pause the standard final action path and route the case to the right queue.

The audit should confirm:

1. Candidate replies are connected to the case.
2. Dispute status blocks final adverse action.
3. The reviewer can see the report, notice, response, and evidence in one place.
4. Any reinvestigation or source check has its own status.
5. Final action cannot proceed until the configured closure condition is met.

This is also where court records automation connects to adverse action. If a dispute turns on a court record, the team needs a repeatable way to revisit the source, capture evidence, and document the result.

Test the failure modes

Do not only test the happy path. A production adverse action workflow should be tested against the cases that create operational risk.

Run test cases for:

1. Missing report attachment.
2. Wrong candidate identifier.
3. Expired or outdated template.
4. Delivery failure.
5. Duplicate notice prevention.
6. Candidate response inside the waiting period.
7. Candidate response after the waiting period.
8. Open dispute.
9. Reviewer rejection.
10. Portal timeout or login failure.

Every failure mode should have a clear result. The automation should stop, retry safely, or route the case. It should not continue with partial evidence.

Measure the right operating metrics

Adverse action automation should be measured with operational and compliance oriented metrics, not only task success rate.

Useful metrics include:

1. Packets prepared per day.
2. Packets rejected by reviewers.
3. Missing attachment rate.
4. Delivery failure rate.
5. Average time in waiting state.
6. Candidate response rate.
7. Dispute routing time.
8. Final notice preparation time.
9. Cases blocked by policy controls.
10. Cases reopened after closure.

These metrics help a CRA see whether the workflow is reducing manual load while also improving control. A high automation success rate is not helpful if reviewers still cannot reconstruct the case.

Use the audit before scaling

Before scaling an automated adverse action workflow, ask these questions:

1. Can operations explain every state?
2. Can compliance see the policy boundary?
3. Can a reviewer stop or reroute the case?
4. Can the team prove what was sent and when?
5. Can the workflow block final action during a dispute?
6. Can the evidence package be reconstructed without asking engineering?
7. Can the team change templates without changing code?
8. Can the workflow be tested against failure modes?

If the answer is yes, automation can remove a large amount of repetitive administrative work. If the answer is no, start by tightening the workflow model.

For the surrounding CRA workflow strategy, read A CRA automation readiness checklist. For adjacent screening operations, see pre employment screening automation.