Digital Onboarding Is Getting Faster and Riskier. What a Community Bank Should Automate Last

The vendor is answering a question you did not ask

You have a four minute account opening flow that takes eleven minutes, and most people who start it never finish. So you called some vendors. Every one of them showed you the same demo: connect the systems, kill the handoffs, watch the exceptions disappear.

That demo is honest about throughput and silent about direction. Onboarding is not one process. It is a sequence of steps that each get faster when automated, and one of them gets more dangerous at the same time. Automate in the order a vendor's implementation plan suggests, which is usually the order that shows the best number soonest, and you will make the whole funnel faster, including the part of the funnel that is not made of customers.

Here is the sentence we end up saying in these engagements. The account opening decision is the last thing you should automate, and it is almost always the first thing that gets automated, because it is the step where the demo looks best.

The two numbers, and why nobody puts them on the same slide

The friction case is real and well documented. Encompass Corporation's 2025 research reported that 86 percent of organisations took direct financial losses from complex onboarding processes, with fragmented automation across legacy tools and manual handoffs named as the cause. On the community banking side, 2026 benchmark work puts average digital application abandonment near 77 percent, and finds that institutions whose flow runs past thirty minutes essentially all lose more than half of their applicants. Time to completion is the single best predictor of whether the deposit shows up.

None of that is vendor fiction. If your flow is slow, you are losing real accounts to a competitor whose flow is not.

Now the other number, which lives on a different set of pages. Roughly 8.3 percent of digital account creations were flagged as suspected fraudulent in the first half of 2025. US lenders carried around 3.3 billion dollars of synthetic identity exposure tied to new accounts in the same period, and 62 percent of banks name digital onboarding as their single highest-risk point for synthetic identity. Estimates of total annual US synthetic identity losses run in the tens of billions.

Both sets of figures describe the same funnel. One is measured in abandoned applications, the other in funded accounts that should never have opened. Every vendor deck we have reviewed shows you the first and not the second, which is not a conspiracy. It is just that the first one is the problem their product solves.

Throughput steps and decision steps are not the same kind of work

Split your onboarding flow into two categories and the sequencing answers itself.

Throughput steps move information. Identity capture, document intake, data validation against the sources you already pull, status communication back to the applicant. Automating these is close to pure gain. They are where the eleven minutes live, they are where abandonment happens, and speeding them up does not change who ends up with an account. A person who was going to pass still passes. A person who was going to fail still fails, just sooner and more cheaply.

Decision steps determine an outcome. Whether this identity is real. Whether the stated purpose of the account is plausible. Whether to fund it, and how fast. These steps do not move information, they convert it into an irreversible action, and speed here has a direction. Faster capture gets you a better completion rate. Faster funding gets a mule account operational before anyone has looked at it.

That is the whole thesis. Automate throughput first, because that is where the loss you are actually feeling comes from. Automate the decision last, and only after you can see what it is doing.

The failure we see most often is a bank that automated in exactly the reverse order, usually because the decisioning module was the flashiest part of the platform and the document intake work was unglamorous integration effort that got deferred to phase two. Eighteen months later, phase two has not shipped, the flow is still slow, and the one thing running unattended is the part that opens accounts.

Community banks are targeted specifically, and they know why

ICBA's own reporting on fraud is blunt about this. Community banks get selected because authentication stacks are lighter and response times are slower than at large institutions, and in a synthetic bust-out there is nothing to recover afterward, because the person on the application does not exist. There is no chargeback, no collections file, no negotiation. There is a funded account, a drawn line, and a name that was never a person.

That changes what a fraud loss means on your books. At a large bank, fraud is a rate managed inside a portfolio. At a 900 million dollar community bank, a bust-out ring that finds a fast, unattended funding path is a quarter.

It also changes what a pilot should look like. The usual advice is to pilot on a low-risk segment. In onboarding, the low-risk segment is defined by the very control you are proposing to automate, which means you cannot pilot your way to confidence in the decision step the way you can with a document classifier. That circularity is worth sitting with before you sign anything, and it is the sort of thing we cover in more depth in our piece on when AI is the wrong answer to an operations problem.

What to ask, and where the honest answer sits

If you are in a vendor process now, three questions separate a real answer from a demo.

Ask what the platform does on the funding step specifically, as distinct from the approval step. Many products treat those as one event. If yours does, the delay you thought you had between an approved application and available money does not exist.

Ask for the fraud rate on accounts opened through the automated path, measured against the manual path, at institutions of your size. Nobody publishes this comparison. Some vendors have it internally. How a salesperson reacts to being asked is itself informative.

Ask what happens to a case the model is unsure about. If the answer is that it goes to a queue, ask who works that queue, how quickly, and whether the same dual control that governs the automated path governs the human one. Usually it does not, and an exception queue worked by one person under time pressure is where controls quietly stop applying.

We wrote a general version of this discipline in our guide to evaluating AI vendors, and the finserv-specific version of the customer experience side sits in our work on mobile-first banking. The onboarding case is where those two pull hardest against each other.

One more thing worth saying out loud. Not every step needs a model. A good deal of onboarding fraud pressure is absorbed by ordinary sequencing choices: what gets verified before funding rather than after, which limits apply in the first thirty days, what a status message reveals to someone probing the flow. Those are free. They are also the first things dropped when a project is being measured on time to completion.

Where this stops being an article

The order to automate in is not a matter of taste, but the right order for your bank depends on things a page cannot see. Where your current losses actually sit. Whether your abandonment is caused by the steps you think it is. What your funding timing looks like today, and who is watching the exception path at four in the afternoon.

Those answers exist inside your flow and your loss data, and finding them takes a week of looking, not a framework. If you are being asked to approve an onboarding automation program and you want a read from someone who does not sell the software, start a conversation with us. We will tell you which steps to move first, and we will tell you if the honest answer is that your process needs fixing before anything gets automated at all.