Carrier download is the mechanism that lets your carriers do your data entry. A policy is written, endorsed, renewed, or cancelled at the carrier; the carrier sends that transaction electronically to your agency; and your agency management system files it against the right customer without anyone re-keying it from a portal.
It is the most valuable integration in an independent agency and the one agents understand least, because it usually gets explained either as marketing (“seamless carrier connectivity!”) or as silence. So here is the actual plumbing, including the parts that go wrong.
The mailbox model
There are thousands of carriers and hundreds of agency systems. Nobody builds that many point-to-point integrations, so the industry routes almost everything through a network in the middle. In North America that network is overwhelmingly IVANS, which connects several hundred carriers and MGAs to agency systems.
The flow is simpler than it sounds:
- Your agency has an IVANS mailbox with its own account number. If you take download today, you already have one.
- You give that account number to each carrier and ask them to turn download on. Carriers normally do this free; it takes a week or several depending on their queue.
- The carrier deposits transaction files into your mailboxon its own schedule — typically nightly.
- Your AMS collects from that mailbox, parses the files, and files each transaction against the matching customer and policy.
The important structural fact, and the one vendors rarely volunteer: the mailbox belongs to your agency, not to your AMS. If you change systems, you re-point the mailbox. You do not re-ask fifteen carriers for permission and you do not lose the connection. Any vendor that positions download as something they own rather than something they read on your behalf has built a lock-in mechanism, not an integration.
What AL3 actually is
Carriers don’t send JSON. They send AL3, the ACORD standard for insurance transaction data, and AL3 is a fixed-position format designed in an era of mainframes and record layouts.
A file is a stream of groups. Each group has a four-character name, then a declared length, then its data. Inside that data, fields live at defined byte offsets: the policy number starts at position X and runs Y characters, the effective date sits at position Z in YYMMDD, premium is a zoned-decimal number with an implied decimal point. There are no field names in the payload. There is no self-describing structure. There is a spec, a byte count, and the assumption that both sides implemented it identically.
Mostly they did. But “mostly” is where the interesting engineering lives, and it’s why every AMS vendor certifies download carrier by carrier rather than flipping one switch. Real carrier files carry per-carrier quirks: an extra filler byte, a field used differently than the spec suggests, a group that runs longer than a naive parser expects.
The transaction types you’ll see
Download is not one thing. It is a set of transaction types, and carriers support different subsets — which is why “we have download with Carrier X” is an incomplete statement.
| Transaction | What it carries | Why it matters |
|---|---|---|
| New business | A newly issued policy with coverage detail | Removes the biggest re-keying job in the agency |
| Policy change / endorsement | Mid-term changes: added vehicle, limit change, address | Keeps your record accurate between renewals — the most common source of stale data |
| Renewal | The renewing term, with any premium change | Drives your renewal workflow and premium-increase calls |
| Cancellation / non-renewal | Coverage ending, with reason and date | Retention alarm and E&O protection — you find out before the client does |
| Reinstatement | Cancelled coverage restored | Prevents a cancelled-in-error record from sticking |
| Claims | New claims, status changes, settlement detail | Lets you service a claim without calling the adjuster for status |
| Direct-bill commission statement | What the carrier paid, on which policies, at what rate | The only practical way to reconcile commission at scale |
| eDocs | Declaration pages, ID cards, notices | Documents land on the account instead of in a portal |
What happens after the file lands
This is the part that separates a good implementation from one that creates work. Four stages:
- Parse. Walk the groups, read fields at their offsets, decode dates and money into real types.
- Match. Figure out which customer and which policy in your book this transaction belongs to.
- Apply. Update the policy, create the claim, post the commission line, attach the document.
- Suspend.Anything the system can’t match with confidence goes to a review queue for a human to resolve in one click.
Stage four is the one that gets skipped, and skipping it is the root of nearly every download complaint you’ve ever heard.
Why matching is the hard part
Parsing AL3 is tedious engineering. Matching is where systems quietly corrupt books. Here is what actually goes wrong, in the order it bites real agencies.
Policy numbers are not unique across carriers
The naive match key is the policy number, normalized — uppercase it, strip the hyphens and spaces. It works right up until two carriers in your book both use a number that normalizes to the same string. A State Farm auto policy written as 12-345 and a Progressive homeowners policy written as 12345 are now the same key.
Two failure modes follow, and both are bad:
- Wrong match. A Progressive endorsement applies to a State Farm auto policy. The system is confident. Nothing warns anyone. Your coverage record for two clients is now wrong.
- Duplicate creation.The system finds no confident match, and instead of asking, it creates a new policy. This is precisely the “my AMS keeps duplicating policies” complaint you see in agent forums about several well-known systems.
The fix is not clever, it’s just discipline: match on policy number plus carrier (by NAIC code) plus line of business, and when more than one candidate survives, send it to a human. Never resolve ambiguity by guessing.
Cancellations are the dangerous one
A wrongly matched endorsement is a data-quality problem. A wrongly matched cancellationflips an active policy to cancelled in your system of record. Your renewal list drops it. Nobody calls the client. If a claim happens, you get to explain to your E&O carrier why your records said the policy was dead.
Consequential, irreversible transactions deserve a higher matching bar than routine ones. If a system will auto-apply a cancellation on a fuzzy match, that is a design decision someone made, and it’s worth asking about in a demo.
Commercial names break person-matching
AL3 hands you an insured name. Split it into first and last, match against your customers, done — unless the insured is ACME PLUMBING & HEATING LLC, which becomes first name “ACME” and last name “PLUMBING & HEATING LLC.” That will never match your business record. Any book with BOP, work comp, or commercial auto in it will hit this constantly, and the symptom is a review queue full of commercial policies that should have filed themselves.
Negative money disappears
AL3 inherits overpunch encoding from its mainframe lineage: the sign of a number is carried in its final character rather than a leading minus. A negative $123.45 arrives as 12345}-style data, not -123.45. A parser that doesn’t decode it reads that value as invalid and drops it.
What disappears: return-premium endorsements and commission chargebacks. Your statement totals drift from the carrier’s and nobody can explain why. If you have ever reconciled a direct-bill statement and been off by an amount that suspiciously resembles a chargeback, this is a plausible culprit.
One byte of drift produces confident, wrong data
The scariest failure mode isn’t an error. It’s a carrier whose layout differs from the spec by a single filler byte, so every field after that point is read one position off. The policy number comes through as XAUTO-12345. The date parses to a plausible but wrong day. Nothing is missing, so nothing gets suspended, and the data looks fine.
The defense is per-field validation — does this date actually parse, does this ZIP have five digits, is this VIN seventeen valid characters, is this premium in a sane range, does this policy number use a plausible character set. Fields that fail validation get held for review instead of written. A suspense queue that only catches missing data will never catch shifted data, and shifted data is worse.
What good looks like
If you’re evaluating how a system handles download, these are the properties that matter more than the carrier count on the website:
- The raw file is retained and re-runnable. When a mapping gets fixed, you reprocess the original rather than losing the transaction forever.
- Re-running is idempotent. Processing the same message twice produces the same result, not a second copy of the policy.
- Ambiguity goes to humans. A review queue with one-click resolution, not a silent guess.
- Matching uses carrier and line, not just policy number.
- Field-level validation, not just presence checks.
- Per-carrier layouts derived from real files, certified carrier by carrier — and a vendor willing to tell you exactly which of your carriers are live rather than implying all of them.
- Your mailbox stays yours. No lock-in through the connection.
Turning download on at your agency
- Confirm you have an IVANS account. If you take download today you do. If not, IVANS will set one up.
- Rank your carriers by premium volume. Four or five carriers usually cover most of a book. Start there; the long tail can follow.
- Request download from each carrierusing your IVANS account number, and ask which transaction types they support — policy, claims, commission, eDocs.
- Connect the mailbox to your AMS and let the first files flow.
- Work the queue hard for the first two weeks.Early exceptions teach the system your book. The queue shrinks fast if the implementation is sound — and if it doesn’t shrink, that’s diagnostic information about the vendor.
Our own setup process is documented on the carrier download guide, including manual AL3 upload for carriers you haven’t connected yet.
What download will not do
It won’t give you every carrier — some regional carriers and MGAs simply don’t transmit. It won’t backfill history; download starts from the day it’s switched on, which is why getting your existing book in cleanly matters (see how to switch your AMS). And it won’t replace judgment: a cancellation notice filing itself perfectly is worthless if nobody calls the client.
What it does do is remove several hours a day of typing that was never the job. If you’re still deciding whether you need a full system of record at all, start with what an agency management system is.
Frequently asked questions
What is a carrier download?
A carrier download is an automated transfer of policy data from an insurance carrier into an agency's management system. Instead of an agent re-keying a new policy, endorsement, renewal, or cancellation from a carrier portal, the carrier transmits the transaction electronically — usually through the IVANS network in ACORD AL3 format — and the AMS files it against the right customer and policy. It is the single largest source of saved data-entry labor in an independent agency.
What is IVANS and do I need an account?
IVANS is the network most North American carriers use to deliver download data to agencies. Your agency has (or gets) its own IVANS mailbox with an account number, you give that number to each carrier, and the carrier begins transmitting your policy data to it. The mailbox belongs to your agency, not to your AMS vendor — which matters, because it means you can point it at a different system without asking permission or losing history.
What is AL3 format?
AL3 is the ACORD standard for exchanging insurance transaction data between carriers and agency systems. It is a fixed-position format: a file is a sequence of named groups, each declaring its own length, with fields sitting at defined byte offsets inside them. It predates modern data formats by decades and is unforgiving — a single byte of drift in a carrier's layout shifts every field after it, which is why parsing AL3 correctly is harder than it looks.
Why does my AMS create duplicate policies from downloads?
Almost always because the system failed to match an incoming transaction to the policy that already exists, and then created a new one instead of asking a human. The usual causes are matching on policy number alone (policy numbers are not unique across carriers), formatting differences such as hyphens or leading zeros, commercial entity names being split as if they were a person's first and last name, or a search that only checks part of the book. A well-built download routes anything ambiguous to a review queue rather than guessing.
How long does it take to set up carrier downloads?
Connecting your IVANS mailbox to an AMS takes minutes. Getting carriers to turn download on for your agency takes longer — typically one to four weeks per carrier, depending on the carrier's process and queue. Carriers normally provide download at no charge. The practical approach is to start with the three or four carriers that make up the bulk of your book and add the long tail over the following months.
What transaction types come through carrier download?
The common ones are new business, policy changes and endorsements, renewals, cancellations, non-renewals, reinstatements, claims activity, direct-bill commission statements, and eDocs such as declaration pages and ID cards. Which of these you actually receive varies by carrier — many carriers send policy transactions but not claims, or personal lines but not commercial. Always ask for the specific transaction types a carrier supports rather than assuming download means everything.