Automate client onboarding where the work is reading and comparing, and test the automation before you trust it with a single packet. That is the short answer for brokerage and advisory accounts at a wealth firm, which is what this guide covers; bank deposit accounts are a different process with different rules. The case for automation is strong because the errors that cause not-in-good-order packets are mostly values that are present and wrong, an account number one digit off the prior statement or beneficiary shares that add up to 90%, and people miss those at volume. The case for testing is just as strong, because a digital form or a tool that extracts fields accurately can still pass every one of those errors. The fair test is to plant known errors in your own recent packets and count what the software catches, what it misses and what it stops by mistake. Wealth Client Onboarding, Botminds' agentic solution for opening wealth accounts, is measured the same way, on the firm's own past packets, before it goes live.
The rules cited are FINRA's, the SEC's, FinCEN's and the IRS's. Results shown from the solution come from its fictional sample firm, Quillfield Private Wealth; they show how a measurement looks, not what any firm will get.
Twelve errors to plant, and the rule each one breaks
- 1. Transfer form account number one digit off the statement
FINRA Rule 11870(d)(3)(C): the account number is not on the old firm’s books.
- 2. Account title that drops a middle initial or uses a former surname
Rule 11870(d)(3)(I): the title does not match the old firm’s records.
- 3. Account type that differs from the statement
Rule 11870(d)(3)(J): individual on the form, joint on the statement.
- 4. Two digits of a tax ID transposed between application and transfer form
Rule 11870(d)(3)(H), and the customer identification rule’s identification number.
- 5. One joint owner’s signature missing from the transfer form
Rule 11870(d)(3)(K): missing or improper authorization.
- 6. TOD or IRA beneficiary shares that total 90% or 110%
The firm’s own good-order rule; the designation cannot be carried out as written.
- 7. A government ID that expired before the opening date
Identity verification under 31 CFR 1023.220(a)(2)(ii), and the firm’s own ID rule.
- 8. An employer on the application that contradicts the CRM
The account record’s employment status under SEC Rule 17a-3(a)(17).
- 9. Form CRS delivered after the account opened, or a superseded version
17 CFR 240.17a-14(c) and the dated record under 17a-3(a)(24).
- 10. Trusted contact page blank, no decline, owners over 65
FINRA Rule 4512(a)(1)(F) reasonable efforts, where the firm’s policy makes it a stop.
- 11. A prior-firm statement older than the firm’s limit
Rule 11870.03 suggests the most recent statement; the age limit is firm policy.
- 12. A W-8BEN signed more than three calendar years ago
IRS: valid to the last day of the third succeeding calendar year after signing.
Should you automate client onboarding?
Yes, for the reading, matching and drafting; no, for the decisions. The parts of onboarding that automate well are the ones where accuracy depends on attention, not judgement: classifying the pages of a packet, extracting every field, comparing the transfer form with the old firm's statement character by character, checking each field against the firm's rules for the account type and drafting one request for what is missing. The parts that should stay with people are the ones the rules give to people: deciding a borderline case, sending anything to a client, clearing a possible sanctions match and accepting the account, which FINRA Rule 4512 assigns to a partner, officer or manager.
The test of a proposal is therefore not "how much does it automate?" but "does it catch the errors that matter, and does it stop at the right line?" Both can be measured before you buy, on your own packets, in about two weeks.
Can an e-signature packet still be not in good order?
Yes, and that is the gap most digital onboarding leaves open. An electronic form with required fields prevents blanks; it cannot know that the account number the client typed is one digit off the statement from the firm they are leaving, that the employer they entered contradicts what they told the advisor last spring, or that the Form CRS link went out a day after the account was opened. Each of those is a comparison between two sources, and a form only holds one of them.
The sample week in the solution shows the proportions. Of 323 packets stopped before submission, the transfer-form comparison alone accounted for 64, and signatures missing or mismatched for 71, even though most packets arrived by e-signature. Required fields had done their job; the errors that remained were in what was filled in.
How do you test client onboarding automation?
Seed known errors into real packets, mix them with untouched ones, and count. The standard to aim for is the one the National Institute of Standards and Technology sets for AI generally: an accuracy figure means little unless it comes with a clearly defined, realistic test set that looks like the conditions of real use, and with the method written down (NIST AI 100-1, AI Risk Management Framework 1.0, January 2023). FINRA's 2026 report makes the same point for firms using generative AI, pointing to thorough testing of what a model can and cannot do, covering privacy, integrity, reliability and accuracy (FINRA, 2026 Annual Regulatory Oversight Report).
Realistic means your own packets: your templates, your custodian's forms, your branches' scans and handwriting. A vendor's demonstration file is clean by construction. The method below takes last month's closed packets, which your team has already judged, and turns them into a test set with a known answer for every field.
Building the test set from last month's packets
| Step | What to do | Why |
|---|---|---|
| 1. Pick the packets | Take 300 closed packets from last month that opened cleanly, across account types, channels and branches, with transfers in about half. | Real templates, scans and handwriting; a known-good starting point. |
| 2. Hold back controls | Leave about 60 untouched. | Counts false stops: a system that stops clean packets costs the client a call. |
| 3. Plant one error per packet | Edit the other 240: each of the twelve errors about 20 times, on the page where it would naturally occur. | Enough repetitions per error type to see a pattern. |
| 4. Hide the key | Keep the list of planted errors with someone outside the test; shuffle the packets. | Nobody tunes the system to the answers. |
| 5. Run and record | Every stop, every amber and every pass, with the page and rule the system cites. | A catch that cites the wrong rule is half a catch. |
| 6. Score against the key | Catches, misses and false stops by error type; time from arrival to a decision. | The numbers in the scoring sheet below. |
How many packets do you need to test onboarding automation?
Enough repetitions of each error to bound the miss rate, and the arithmetic is simple. If a system misses a given error with probability p, the chance it catches all n planted copies is (1 − p)n. Setting that to 5% gives the familiar "rule of three": if it catches all n, you can be about 95% confident its miss rate for that error is below roughly 3 ÷ n.
What a clean run proves, by the number of planted copies
10copies
all caught: miss rate likely below about 30%
20copies
all caught: likely below about 15%
60copies
all caught: likely below about 5%
300copies
all caught: likely below about 1%
The numbers argue for a two-stage test. Twenty copies of each of twelve errors, 240 packets, is a realistic first pass and will separate systems that catch an error type from systems that do not. For the two or three error types that cause most of your rejects, typically the transfer-form mismatches, a second run of 60 or more copies each tells you whether the catch rate is good enough to rely on.
How to score it: catches, misses, false stops and citations
Score four things per error type, not one overall percentage. A single "accuracy" figure hides the failure that matters most: a system can be 98% accurate across all fields and still miss most transposed account numbers, because those are a small share of fields and a large share of rejects.
The scoring sheet
| Measure | How to count it | What good looks like |
|---|---|---|
| Catch rate, by error type | Planted errors stopped or sent to a person ÷ planted errors of that type | Every type caught most of the time; the transfer-form types nearly always |
| Misses | Planted errors the system passed as in good order | Each one read: is it a reading failure or a missing rule? |
| False stops | Stops on the untouched control packets | Low, and each one explainable from a real ambiguity |
| Correct citation | Catches that name the right page and the right rule | Close to every catch; a wrong citation sends the specialist hunting |
| Changes it made itself | Fields the system altered rather than flagged | Zero: a correction needs the client |
| Time to a decision | Arrival to a specialist’s decision, for stopped packets | Minutes for a clear red; the person’s time, not the system’s |
Two of those rows are about restraint. "Changes it made itself" should be zero, because a value on a signed form belongs to the client; the solution's Transfer Matcher never changes a number and asks for the client's initial instead. And a catch that cites the wrong rule is worth less than it looks: the specialist has to rediscover why the packet stopped, which is the work the automation was bought to remove.
Wealth Client Onboarding stamps every field of a packet where it sits, green, amber or red
What errors should a new account check catch that people miss?
The ones that live between documents. A reviewer reading a transfer form on its own sees a well-formed account number; only the statement shows it is wrong. A reviewer reading the application sees a plausible employer; only the CRM shows the client retired. A reviewer reading the Form CRS receipt sees a date; only the account's opening time shows the date was late. Planted errors 1 to 4, 8 and 9 in the list above are all of this kind, and they are the ones to weight most heavily in the score.
The second group lives in arithmetic and calendars: beneficiary shares that do not total 100%, an ID that expired last month, a W-8BEN that, under the IRS's instructions, stays in effect only until the last day of the third calendar year after the year it was signed (IRS Instructions for Form W-8BEN). These are easy for software and tedious for people, which is exactly why they slip through at the end of a long day. The full list of fields the account record needs, and the rule behind each, is in the FINRA Rule 4512 field-to-source map.
What the sample firm's rules stopped in one week
A live system gives the same picture continuously that the planted test gives once. The solution's settings show each of the sample firm's 14 good-order rules, what it does, a stop, a decision for a person or a referral to anti-money-laundering review, and how often it fired.
Wealth Client Onboarding's sample week: how often each good-order rule fired
Read the chart as a planted-error test would be read. The rules that fire most are the ones to plant most often in your own test, because they are where your packets go wrong. The "person decides" rules are the ones to score for false stops, because each costs a specialist's time even when the packet is fine. And the three referrals to anti-money-laundering review are the cases where a catch is not a stop at all: the system's only job is to route them, since no agent can clear a match.
Good-order rules in Wealth Client Onboarding: each a setting, with its action and its count
What should automated client onboarding software never do?
It should never approve, submit, send anything to a client unseen, clear a sanctions or identity match, change client data or waive a rule. Those six limits are what make the automation safe to run at full volume, and each can be tested: plant a case and confirm the system stops short. In the solution these limits are part of the design: agents read, check and draft, a specialist sends, an anti-money-laundering analyst clears matches and a registered principal approves.
The sample firm's own go-live measure follows the same idea at larger scale: a set of 1,200 of its past packets, reviewed against the decisions its people actually made, with the chief compliance officer's approval required before the agents go live or change. A planted-error test is the buyer's version of that, smaller and sharper, and the independent second reader is the design feature it most often exposes. What each error costs when it gets through is worked out in the cost of a not-in-good-order packet.
Questions people ask
What does it mean to automate client onboarding?
For a wealth firm it means software that reads each account-opening packet, extracts every field, checks it against the firm's rules and the other documents, and drafts the request for anything missing, so people spend their time on decisions. It does not mean removing the specialist's review or the principal's approval, which the rules and good controls keep with people.
How accurate are account opening tools?
No regulator or independent study publishes accuracy figures for brokerage onboarding tools, and vendors' figures come from their own test files. The only accuracy number worth having is one measured on your own packets, by error type, with planted errors and untouched controls, as described above.
How long does a planted-error test take?
About two weeks for a first pass: a few days to select and copy last month's packets and plant the errors, a few days for the system to process them, and a few days to score. A second, larger run on the error types that cause most rejects can follow if the first pass is promising.
Is this the same as testing digital account opening at a bank?
No. Bank deposit accounts run under different rules and rarely involve transferring a securities account from another firm. This test is built for brokerage and advisory accounts, where FINRA Rule 11870, Rule 4512 and SEC Rule 17a-3 decide what good order means.
Should test packets ever leave the firm?
Only under the same data-protection terms as live data. The packets carry real customers' information, so the test runs inside your systems or the vendor's environment under your security review, on copies, and nothing is sent to clients or custodians. The SEC's amended Regulation S-P requires oversight of service providers that handle customer information.