Regulated ops still runs on browser portals

The easiest automation story is an API story. A clean trigger arrives, a workflow calls another clean API, and the result lands in the right system.

That is not how a lot of regulated operations work.

Consumer reporting agencies, insurance operations teams, revenue cycle teams, and finance teams still run critical work through browser portals. A person logs into a court records site, a payer portal, a bank portal, an employer system, an ATS, a vendor dashboard, or a government site. They type values, download PDFs, compare records, wait for a result, and document what happened.

The browser step is not incidental. It is where the work happens.

Why this work is hard to automate

Regulated ops workflows usually have three problems at once.

First, the source systems are fragmented. A CRA might handle court searches, education checks, employment verification, identity checks, and adverse action steps across many portals. An insurance team might check eligibility across multiple payer sites. A finance team might retrieve statements, invoices, tax documents, and remittance files from vendor and bank portals.

Second, the workflow needs judgment boundaries. Teams need rules about when to pause, when to route to a reviewer, when to send a notice, and when to wait. The automation should not erase policy ownership. It should make the repetitive steps consistent while leaving compliance and review decisions with the team.

Third, the audit trail matters. It is not enough to know that a script finished. The team needs to know which input was used, which page was opened, what was downloaded, when the notice was sent, and where the output landed.

That is why generic browser control is only the beginning. The workflow layer matters more.

Background screening is the clearest example

Background screening teams know this problem well. The work is high volume, portal heavy, and compliance sensitive. Researchers and ops specialists often repeat the same lookup or verification sequence hundreds of times, then log the result back into a case system.

Komos was built around that pattern. On the background screening automation page, we show how Certn uses Komos in production for CRA operations. Their teams have automated 500,000 plus manual actions and removed 1,500 plus hours of manual portal work per month.

The same pattern shows up in adjacent workflows:

1. FCRA adverse action automation, where the team needs notices, wait windows, delivery records, and reviewer control.
2. Pre-employment screening automation, where the task spans identity, criminal records, verification checks, and candidate communication.
3. Court records automation, where the work depends on jurisdiction specific portals and repeatable evidence capture.

Insurance and banking have the same shape

Insurance eligibility verification looks different on the surface, but the operating model is similar. A team receives a patient or member record, logs into a payer portal, checks coverage, captures the result, and writes structured data back to an EHR, PMS, spreadsheet, or revenue cycle system. The workflow needs credentials, screenshots, logs, and exception routing.

Banking and finance operations have another version of the same problem. A team needs to retrieve statements, download remittance files, check balances, compare invoices, or reconcile transactions inside portals that were designed for human use. The input may start in an ERP, but the actual retrieval step still happens in a browser.

This is why we think of Komos as an automation layer for regulated operations, not just as a browser agent. A Komos task can browse, but it can also call APIs, parse documents, write outputs, notify reviewers, run on a schedule, and preserve a run history.

What to require from the automation layer

For regulated ops, the checklist should be stricter than "can it click the button?"

The automation layer should support managed credentials, repeatable inputs and outputs, screenshots, downloaded artifacts, timestamps, retry behavior, human review points, and a way to call the workflow through an API or schedule.

It should also be owned by operations and compliance, not only engineering. Engineering should not have to patch every portal flow because a page label moved or a reviewer needs one extra field in the notice.

That is the layer Komos focuses on. Moss can build the workflow from a demo or process brief, but the task stays inspectable. Ops can run it. Compliance can review it. Engineering can integrate it through the API when the workflow needs to sit behind another system.

If the work depends on portals, documents, credentials, and review, the goal is not to replace the browser. The goal is to make the browser step part of a controlled, auditable operation.