AI for Underwriting in Technology

A seller completes a signup form on a Tuesday afternoon. A trading name, a company number, a category chosen from a dropdown, a payout account, and a website live for a fortnight. Behind that form somebody has to decide whether money may move through the platform, how much to hold back, and for how long. The seller expects to be taking payments by the end of the day.

That is underwriting in a technology business, and it resembles almost nothing of the version used elsewhere.

Nobody here is writing a policy

The technology companies that underwrite are payments platforms, marketplaces, embedded finance providers and software businesses that have started lending or holding settlement risk for their customers. What they underwrite is a business: a merchant taking cards, a seller shipping goods, a host letting a property, a driver drawing earnings early, a borrower using working capital inside the product they already pay for.

There is no policy, no premium and no actuarial table. The question is narrower. If this business fails or disappears, who holds the money already paid out? Usually the platform, and behind it a sponsor bank that will ask why the business was accepted.

An afternoon is the whole budget

In most underwriting functions the binding constraint is cost. Here it is time. The entire product promise is that a business can sign up and transact the same day, and every minute of review is spent against that promise. A review queue that is accurate and slow has already lost the account to a competitor who answered in minutes.

This changes what good looks like. The goal is not the most thorough file but the most defensible decision reachable inside the window, naming what was not checked and what will be watched instead.

The merchant's own description of itself is the weakest input

Every onboarding flow asks the business what it does, and that answer is the least reliable thing in the file. Sometimes it is dishonest. Far more often the dropdown had no option that fitted, so somebody picked the nearest thing and moved on.

So the file holds competing versions of the same business. The form says general retail. The website sells a subscription with health claims on the landing page. The processing pattern, once volume arrives, says something else again: order values far above the stated category, a long gap between payment and delivery, a wave of first time cards from one region. The last version is the true one.

The file an underwriter should not have to build

Most of the work between signup and decision is retrieval and comparison. Pull the registry extract and confirm the entity exists, is active and has filed what it should. Read the uploaded documents: incorporation certificate, bank statement, identity and address evidence. Visit the live site and record what is actually sold, what the delivery promise is, whether terms and contact details exist. Set all of it against the declarations on the form.

An agent does this well because the task is bounded, repetitive and evidence driven. The output should be a file in which every statement carries its source: this trading address came from the registry extract, this one from the uploaded utility bill, this product range from the site navigation on the day it was read. A claim without a source is not evidence and should not appear.

Naming the disagreement instead of settling it

The valuable behaviour is restraint. When the registry, the documents and the site disagree, the agent should state the disagreement precisely and stop. The director named on the form does not appear on the register. The payout account is held in a name similar to but not the same as the applicant.

A model that quietly resolves those conflicts into a tidy recommendation destroys the only signal worth having. A referral note saying here are two facts that cannot both be true, with both sources attached, beats a confident verdict.

Ownership layers, and the point where names become people

Beneficial ownership work is unwrapping. A holding company owns the applicant, another entity owns that, and eventually there are people, or a register that does not publish them. An agent can traverse the layers it can reach, assemble the chain, and show where the chain breaks: a jurisdiction with no public filing, a nominee service address that appears on unrelated companies, a shareholder that is itself a trust.

What matters is that the break is reported as a break, not inferred away so the diagram looks complete.

Screening a name that is not quite the name

Sanctions and adverse media screening is where the false positives live. Names transliterate several ways, common names collide constantly, and the alert that matters looks identical to the ones that do not.

An agent helps with preparation, not the decision. It can gather the discriminating evidence for a probable false match, the age that does not fit, the residence on file against the one in the listing, and present it as an analyst needs it to clear or escalate quickly. It should never be the thing that decides a match is not a match.

Permitted, restricted, prohibited, and the argument in between

Every platform has a category policy, and most enforcement is keyword based, which makes it both too strict and too loose. A supplement retailer may be acceptable or restricted depending on the claims printed on the product page. A top up store for game currency can be ordinary commerce or a money transmission problem.

This is a reasoning task and one of the clearest wins available. The agent reads the policy clause, reads the actual page text, and writes the argument: this is the clause, this is the wording on the site, this is why it falls inside or outside, and this is the one fact that would change the answer. A keyword flag tells a reviewer nothing and has to be redone from scratch.

The money you may have to give back

Settlement risk is mostly about timing. Exposure is not the merchant's revenue, it is the money paid out against goods not yet delivered, plus whatever can be reversed afterwards. A business that ships next day carries little. One taking deposits for furniture delivered next season carries a great deal, and so does one selling tickets for an event months away.

An agent can model that exposure from what the site and the early processing show: delivery lead times stated in the terms, the pattern of pre authorisations, refund behaviour in the first weeks, dispute reasons as they arrive.

Rolling reserves and payout delay

The mitigations are reserves, rolling reserves, payout delays and exposure limits, and each taxes a legitimate merchant's cash flow to protect the platform. Preparing those options with the evidence behind each is good agent work. Choosing among them is a commercial decision, and it belongs to a named person.

Approval is not the decision that matters most

The portfolio is enormous and overwhelmingly long tail, so almost no file is reopened unless something forces it. The initial decision is made on the thinnest evidence the file will ever contain. Everything informative arrives afterwards.

Changes that should reopen a file

Volume stepping up by an order of magnitude in a week. Product mix shifting into a category that was never declared. New words appearing in payment descriptors. A sudden rise in pre authorisations. A change of payout bank details, especially just after a volume increase. Dispute ratios creeping toward the threshold rather than jumping over it.

Each of those is an underwriting event, and watching for them across the book is work no team can staff by hand. An agent can hold that watch continuously: assembling the evidence for a change, drafting the note, and putting the file in front of a person who would otherwise never look at it again.

Bad approvals do not announce themselves

A bad approval is invisible at the moment it is made. It surfaces months later as a wave of chargebacks for goods never shipped, by which time the merchant has withdrawn the balance and stopped answering email.

That delay breaks the feedback loop any learning system needs. Outcome labels are sparse, late and biased toward the businesses you approved, so evaluation has to lean on process quality instead: was every claim sourced, was each disagreement surfaced, would a reviewer have reached the same decision from the same file.

A decline the merchant can act on

The least glamorous win is probably the largest. Most declines at onboarding are not fraud. They are a blurred document, a name that did not match the register because the business trades under another one, an address that moved. Those businesses are told no in terms too vague to act on, and they churn.

An agent that writes a decline clearly, naming which check failed and what evidence would change the answer, recovers revenue never truly at risk, and spares you the appeal that arrives as an angry support ticket with no file attached.

Where AI fails here

A decline is an adverse action with regulatory and contractual consequences. A reason you cannot defend is worse than giving none, and a plausible sounding explanation generated after the fact is the worst outcome available.

Sanctions screening is a legal control, not a best effort classification. Tuning match thresholds on a model's judgement is not acceptable to a regulator or a sponsor bank, and no amount of measured accuracy makes it so.

Open internet evidence is precisely where models fabricate with confidence. An unsourced sentence in an underwriting file is not weak evidence, it is a liability. Every claim carries its origin or it is dropped.

Adversaries adapt. A merchant structuring itself to look ordinary is optimising against your published criteria, and the better documented your checks, the more precisely they can be satisfied by someone who never intended to trade honestly.

Risk appetite is not a modelling output. How much exposure to carry, which categories to accept, where reserves sit: these are commercial positions owned by people who can be held to them.

Where to start

Pick the narrowest slice with real volume: one geography, one merchant category, one acquiring relationship. Build the evidence file for every applicant in that slice, sourced claim by claim, and let humans keep deciding as they do now. Compare what the agent assembles against what underwriters actually gathered, and measure the time from signup to a reviewable file. That tells you whether the assembly can be trusted before anything rests on it.

Then add the post approval watch over the same slice, because that is where the losses are and nobody is looking. Decisions, reserves and screening dispositions stay with the people who own them.

Adopt AI Partners works on the assembly and monitoring layers of this problem rather than the decision itself. To talk it through against your own onboarding flow, hello@adoptaipartners.com.