ACAT Transfer Paperwork Automation: Cut NIGO Rejections

Your client's account gets rejected by the receiving custodian. Not because the client did anything wrong. Because the registration on the new transfer form reads "John A. Smith, Trustee" and the account title at the old firm says "John Smith TTEE." Same trust, same person, same money. The strings don't match, so the whole instruction bounces and you're back to square one.

If you run ops at a small RIA, this isn't a one-time onboarding headache. It's a recurring line item. A client adds a trust. A beneficiary gets updated. Your firm switches broker-dealers and has to repaper forty accounts at once. Every one of those events runs back through the same transfer machinery, and every one of them can get kicked back for the same handful of avoidable reasons. You don't have a compliance team or a dedicated ops department to absorb this. You have you, a spreadsheet, and a stack of forms you're re-checking by eye.

What a rejected transfer actually costs you

The industry term for a rejected transfer is NIGO: Not In Good Order. The transfer instruction went out, and the custodian on the other end sent it back because something on the form didn't line up with what they had on file.

The mechanics of a transfer are governed by FINRA Rule 11870, the rule that sets up the Automated Customer Account Transfer Service most firms use to move accounts between custodians. Under that rule, the carrying firm (the one giving up the account) has one business day to either validate the transfer instruction or reject it, and three business days to complete the transfer once it's validated. That's a tight, well-defined clock for a clean transfer. It says nothing about what happens when a form gets rejected and has to be corrected and resubmitted, because at that point you're not in the rule's timeline anymore. You're back at the start of an informal loop: fix the mismatch, resubmit, wait for the one-day review again, hope it clears this time.

That loop is where the real cost sits. The assets in transit aren't earning you a fee until the transfer settles, so a rejected transfer is billable AUM sitting idle for however long it takes to fix. Meanwhile someone on your team, often the only ops person you have, is pulling up the old account statement, comparing it field by field against the new form, and calling the client to ask a question they already answered once. None of that shows up as a line item anywhere, but it's real hours, and at a small firm those hours come out of time that should be going to clients, not paperwork archaeology.

The other cost is less visible and harder to forgive: client experience. A transfer that should take a week and takes three because of a name mismatch is the kind of thing a client notices and remembers, especially if it happens right when they're deciding whether moving to you was the right call.

The four reasons transfers actually get rejected

Custodians don't reject forms randomly. In practice, NIGO rejections cluster around a small number of causes, and once you know what they are, you can start catching them before submission instead of after.

Name and registration mismatches. This is the trustee example above, but it also covers simpler cases: a maiden name still on file at the old custodian, a middle initial present on one form and missing on the other, a business name abbreviated differently across two systems. The custodian's system does a literal string match in a lot of cases, not a "does this obviously refer to the same person" match, so small formatting differences are enough to bounce the form.

Account-number mismatches. The account number on the transfer form has to match what the carrying firm has on record, exactly. This trips up transfers most often when an account was renumbered after a merger or system migration at the old firm and nobody flagged it before the new form went out.

Registration-type mismatches. Individual, joint tenants with right of survivorship, tenants in common, trust, custodial, corporate. The registration type on the incoming form has to match the registration type on file, and it's easy for this to drift, especially after a life event like a marriage, a divorce, or a death that changes how an account should be titled but doesn't automatically update every record that references it.

IRA-type mismatches. Traditional, Roth, SEP, SIMPLE, inherited, and inherited-Roth IRAs all have different tax treatment, and custodians are strict about matching the IRA subtype exactly, not just "yes, it's an IRA." An inherited IRA transferred as if it were a standard Traditional IRA gets flagged fast, because the tax handling on the receiving end would be wrong if it went through.

None of these are new-client-only problems. They show up just as often when an existing client changes a beneficiary, when a trust gets amended, when your firm changes broker-dealers and repapers the whole book, or when a client asks to move part of a position to a different custodian mid-relationship. If your process only checks for these issues at intake, you're covering maybe a third of the situations where they actually happen.

How a custom system catches this before the custodian does

The fix isn't a better checklist. A checklist still depends on someone remembering to run it, on a Tuesday afternoon, on the fortieth form of the week. The fix is a system that reads the transfer form and the supporting documents the same way a careful ops person would, and flags a mismatch before the form ever leaves your building.

In practice, that looks like a document-intelligence layer that pulls the structured fields off the Transfer Initiation Form and any supporting registration documents, then cross-references them against what your firm's CRM (Redtail, Wealthbox, whatever you run) or your existing custodian records already have on file for that account. Legal name, account number, registration type, IRA subtype, all checked against the system of record before the form goes anywhere. If the trustee is listed as "John A. Smith" on your CRM and the new form says "John Smith," the system flags it right there, before submission, instead of three days later when the custodian sends it back.

This is the "alongside, not instead of" point that matters here. The system doesn't decide how an account should be titled or make the judgment call on an ambiguous registration. Your ops person still does that. What changes is that they're reviewing a flagged discrepancy the system already found, instead of catching it by luck or not catching it at all and finding out from a rejection notice a week later. The forty-account repapering event that used to mean days of manual cross-checking becomes a batch the system runs through in minutes, with the exceptions surfaced for a human to resolve.

The business outcome is straightforward: fewer round trips through the one-day-review, three-day-complete cycle in FINRA Rule 11870, which means AUM starts earning its fee sooner and your ops person spends less of the week playing detective on forms that shouldn't have gone out with a mismatch in the first place.

Will this work with my custodian's portal, or is this a big IT project?

This is the question that actually stops solo and small RIAs from doing anything about NIGO rejections, and it's a fair one. You don't have an IT department, and the idea of ripping out your Schwab, Fidelity, or Pershing relationship to bolt on some new platform is a nonstarter.

It shouldn't require that. The document-checking layer sits on top of the paperwork and data you already have. It reads the forms you're already generating and the account records you already keep in your CRM or custodian portal exports. It doesn't need you to change custodians, consolidate onto a single platform, or hand your client data to a third party's servers. A system built this way runs in your firm's own cloud environment, so account numbers, registration details, and client records stay inside infrastructure you control, not inside someone else's shared database. That matters for the same reason your compliance program already cares about where client data lives and who can see it: a custodian-agnostic check that works the same way whether the account is moving to Schwab, Fidelity, or Pershing is worth more to a small firm than a tool that only works if you standardize on one custodian's proprietary transfer tool.

Frequently asked questions

What does NIGO mean in a securities transfer?

NIGO stands for Not In Good Order. It's the industry term for a transfer instruction, or any account paperwork, that a custodian rejects because a required field is missing, incorrect, or doesn't match what's on file at the carrying firm. A NIGO rejection sends the form back for correction and resubmission rather than letting the transfer proceed.

Why do ACAT transfers get rejected most often?

The most common causes are name or registration mismatches between the two firms' records, account-number discrepancies, registration-type mismatches (individual versus joint versus trust, for example), and IRA-type mismatches such as confusing a Traditional IRA with an inherited IRA. Most of these come down to the receiving custodian's system doing an exact match against the carrying firm's records, so even a small formatting difference can trigger a rejection.

How long does an ACAT transfer take if it gets rejected?

FINRA Rule 11870 gives the carrying firm one business day to validate or reject the transfer instruction, and three business days to complete the transfer once it's validated. A rejection resets that process: the form has to be corrected and resubmitted, and the one-day review clock starts again. There's no rule-mandated ceiling on how long the correction-and-resubmission loop can take, which is why a single NIGO rejection can add a week or more to what should have been a routine transfer.

Can this work across Schwab, Fidelity, and Pershing without a separate integration for each one?

Yes, if the system is built to read and validate the data your firm already produces, rather than requiring a proprietary connection into each custodian's platform. A document-intelligence layer that checks transfer forms against your CRM and existing records works the same way regardless of which custodian is on the other end of a given transfer, which is what makes it usable for a firm that moves accounts across more than one custodian without needing a separate IT project for each.

See what paperwork delays are actually costing you

Before you book a call with anyone, it's worth seeing the number for your own firm. Our document processing cost calculator takes about two minutes, needs no email address, and gives you a rough estimate of what manual paperwork handling, including transfer rework, is costing your team in hours and dollars.

If the number is bigger than you expected, or you want to talk through how a document-checking system would fit your specific custodian mix and CRM, book a free strategy call. We'll look at your actual transfer volume and rejection patterns, not a generic pitch.