Why ACAT Transfers Keep Getting Rejected as NIGO

A client wants to move her accounts to your firm. She has already signed the engagement letter. The transfer paperwork goes out to her old custodian on a Tuesday, and by Friday it is back in your operations queue, unprocessed, with a single line explaining why: the account title does not match. Nobody did anything wrong, exactly. The client wrote her name the way it appears on her driver's license. Her old custodian has her on file the way she signed up fifteen years ago. Now the transfer waits for a second signature, a second submission, and another week the client did not expect to spend.

This is the ACAT rejection problem, and if you run a registered investment adviser (RIA) of any real size, you already know it by its industry name: NIGO, short for "not in good order." It is not a rare event. It is a recurring tax on every new client relationship and every account consolidation your firm processes, and it lands on the same operations staff who are also trying to onboard new clients, prepare for the next SEC exam, and keep quarterly reports on schedule.

Here is what matters most:

• NIGO paperwork is one of the most common reasons an Automated Customer Account Transfer (ACAT) gets rejected outright, and the leading cause is rarely the client's fault; it is a mismatch between what the client wrote and what is already on file.
• An older FINRA industry review put the hard-rejection rate for account transfer instructions at 11 to 13 percent. Treat that figure as a historical baseline rather than today's exact number, but the underlying cause it identified (account information that does not match exactly) has not gone away.
• The transfer system itself is getting faster: DTCC, the organization that actually processes ACATS instructions industry-wide, removed a settlement-preparation step from the process, effective October 17, 2025, bringing a clean transfer down to three to four business days. A rejected one still restarts the clock.
• A pre-submission check that compares the paperwork against your own client record before it ever reaches the custodian catches the same errors a NIGO rejection catches, except before the client loses a week.
• This is not a system that replaces the person who reviews and submits transfer paperwork. It catches what a busy afternoon makes easy to miss, so the review that does happen is a real review.

The real cost of a transfer that comes back

Every NIGO rejection carries two costs, and firms tend to notice only the first one.

The first cost is the delay itself. A transfer that should have taken three to four business days under DTCC's current process now restarts, often adding a full week or more once the corrected paperwork is drafted, re-signed, and resubmitted. During that week, the client's assets sit at the old custodian, out of your firm's management, so the account is not being billed or rebalanced, and the client is not yet getting the advice that was the reason she moved to you in the first place. It is the same operations bottleneck we described in the quarterly report that takes three days to build and still has errors: a firm's most limited resource is not client demand, it is the operations hours available to process it correctly the first time.

The second cost is harder to see on a spreadsheet but larger over time: the operations hours spent chasing the fix. Someone has to notice the rejection came back, work out exactly which field or signature caused it, contact the client for a correction, and resubmit. In our experience advising firms on where their staff time actually goes, this kind of exception-handling work is rarely logged as its own line item. It gets absorbed into "onboarding," which makes it invisible in a headcount conversation and very visible in a staff member's actual week.

The economics get worse at scale. A solo practice that opens a handful of new accounts a month can absorb one NIGO rejection with an afternoon of extra work. A firm running $150 million to $3 billion in client assets, with new accounts and consolidations happening every week, is running the same exception-handling process dozens of times a quarter, using the same two or three operations staff who are also responsible for the firm's annual compliance review under SEC Rule 206(4)-7 and its Rule 204-2 books-and-records obligations. Every hour spent re-chasing a signature is an hour not spent on the work that is actually mandated.

Why the paperwork fails, in practice

Most of what we see when a transfer bounces back NIGO traces to one of two causes, neither of which requires the client to have done anything careless.

The first is a signature or name mismatch. The receiving custodian expects the client's name to appear exactly as it is registered on the account being transferred. A client who has married, has a compound surname, or simply signs her everyday name differently from her legal name on file creates a mismatch the old custodian is required to flag, not waive. A close relative of this problem is an incomplete or inconsistent field elsewhere on the form: account type, account number, or the "full or partial transfer" designation. A Traditional IRA has to transfer into a Traditional IRA; a joint account has to match on both ends. One blank field, or one answer that technically responds to a different question than the one being asked, is enough for the receiving firm to send the whole packet back rather than guess.

The second cause is the one most advisers do not expect, because it is not the client's error at all: stale account data on the receiving end. Consider a client we will call Priya, who asked her advisor to consolidate two old retirement accounts into the IRA the firm already managed for her. Priya filled out the new transfer form with her current legal name. The firm's own client record, created years earlier when she first onboarded, still carried an old address and an account title that had never been updated after a life event. The paperwork Priya submitted was correct. The record it was being checked against was not, and the transfer came back NIGO anyway.

That second cause is the one a purely client-facing fix cannot solve, because the client did nothing wrong. It requires the firm's own records to be accurate and current before the paperwork ever gets drafted, which is a data problem as much as a paperwork problem.

How a pre-submission check actually catches this

The fix is not a better transfer form. It is a document review step that happens before the form leaves your building, built on the same information your operations team already has.

Here is what that looks like in practice. When a transfer packet is ready to go out, the system checks the client's name and account title on the new paperwork against what is already recorded in your CRM, whether that is Redtail, Wealthbox, or Orion, and flags anything that does not match exactly, the same way the receiving custodian's own back office will. It also checks that every required field on the form is filled in and internally consistent, so a blank field or a mismatched account type gets caught before it becomes the custodian's problem to reject. And it checks the age of the client data being relied on. If an address, a name, or an account title in your own CRM has not been updated in a meaningful amount of time, that record gets flagged for a human to confirm before the transfer goes out, instead of showing up as a rejection two weeks later.

None of this replaces the person who reviews and submits the transfer. What it changes is what that person is reviewing. Instead of proofreading every field on every form under time pressure, your operations associate is confirming a short list of things the system has already flagged, and signing off on packets the system has already checked once. The signature that goes on a DocuSign envelope, and the judgment call about whether an exception is genuinely fine to submit anyway, both stay with your team. The system's job is narrower: catch what a busy afternoon makes easy to miss, before it costs the client a week.

Security, access, and the audit trail this creates

For a firm in the $150 million to $3 billion range, this is one piece of a broader wealth management automation decision, and the question that comes up before any of it gets approved is not "does it work," it is "where does our client data go, and who can see it."

The answer we build to is straightforward: the validation system runs inside your firm's own cloud environment, not a shared third-party database that also holds other firms' client information. Access follows the same role-based permissions your firm already uses for who is allowed to submit a transfer in the first place; adding a pre-submission check does not widen who can see a client's account number or Social Security number, it narrows how often a human has to retype one. And every check the system performs, and every flag it raises, is logged with a timestamp, which becomes part of your own record-keeping rather than a separate system your compliance officer has to reconcile against.

That last point matters more than it might first appear. SEC Rule 204-2 requires RIAs to keep books and records, including the documentation behind client transactions, and an auditable log of exactly what was checked and when on a transfer packet is the kind of record an examiner appreciates seeing volunteered rather than assembled after the fact. The goal is not to add a new compliance obligation. It is to make the existing one easier to demonstrate.

Frequently asked questions

What does NIGO mean in a transfer context?

NIGO stands for "not in good order." It is the industry term for new-account or account-transfer paperwork that a custodian sends back because a signature, a field, or a piece of account information does not meet its requirements. It does not necessarily mean the client did anything wrong; it means the paperwork, as submitted, could not be processed as-is.

Why do ACAT transfers get rejected so often?

The most consistent cause identified in industry review is account information that does not match exactly between the transfer instruction and what the losing firm has on file, often because of a name change, a system change on the losing firm's side, or an account title that was never updated. A rejected transfer restarts the process rather than being fixed in place, which is why prevention before submission matters more than a fast correction after.

How long does an ACAT transfer take if nothing goes wrong?

Following an October 2025 process change at DTCC, the organization that operates the ACATS system, a clean transfer typically completes in three to four business days. A transfer that comes back NIGO does not simply resume from where it left off; the corrected paperwork has to be resubmitted, which can add a week or more depending on how quickly the client can be reached for a fix.

Does a pre-submission check replace the person who currently reviews transfer paperwork?

No. The system flags mismatches, incomplete fields, and stale account data before a packet is submitted; a person on your operations team still makes the final call on what gets sent and signs off on any exception. The intent is to give that reviewer a shorter, more accurate list of things to check, not to remove the review itself.

If rejected transfer paperwork is costing your operations team hours it does not have, the conversation worth having is not about buying more software. It is about where, specifically, in your own process, a client's file and a client's signature stop matching, and what that is worth fixing. Book a Free 30-Minute Strategy Call at cal.com/chronexa/30min and we will walk through your firm's actual transfer and onboarding paperwork, not a generic demo, to show where the mismatches are likely coming from.

Read next: Financial Services & Quant AI