Conclusion first: the determination follows three layers—'account → subject → link'—not counting sales by each link one by one
In the morning, when opening the backend, there is an additional commercial liability insurance verification prompt on the Account Health page; a valid policy must be submitted within the specified period, otherwise selling privileges may be restricted. Most people's first reaction is to open the inventory page and look at sales by ASIN one by one to determine which link needs insurance—this direction is wrong from the first step.
Amazon's insurance obligation attaches tothe account and the legal entity behind itnot to a single listing.
Links become the main focus only at two moments: when a claim occurs and it is necessary to determine which product the incident corresponds to, and when certain category reviews additionally require credentials. Therefore, the correct determination order has three layers: whether the account falls within the scope covered by the new rule → who the registered entity of this account is → which links are worth proactively supplementing insurance for. The first two layers determine 'whether to buy and in whose name to buy'; only the third layer concerns individual links.
This article does not repeat the announcement verbatim; it only explains actions that can be executed the same day.
All thresholds, deadlines, and coverage figures are governed solely by the notice you receive in your backend and the original official announcement (this article was checked against publicly available content on the Seller Central announcements page, with a check date of 8/12/2026). If you are also flagged by risk control or another review at the same time, you can combine the responses to both into a single process; refer toFour configuration blind spots in multi-account environment isolation.
Layer one: whether your account falls within the scope of the new rule dated 11/2
The trigger criteria are usually “sales over the past 12 consecutive months reaching a certain threshold,” further qualified by region and currency, for example calculated based on USD sales on the US marketplace.
The specific threshold is subject to the announcement; do not use versions circulating online to work backward and decide whether you need to buy it, because the criteria may be set separately by marketplace and by settlement entity.
The place to self-check is the Account Health page in Seller Central; the insurance verification entry point sits under Account Health. At the same time, check your registered email and performance notifications; once triggered, you will generally receive clear guidance with a deadline. When making the determination, remember two points:
- Look at the total for the entire store, not an individual listing.The threshold applies to the account's cumulative sales on that marketplace, not a specific ASIN. Calculating by listing will only lead to a wrong conclusion.
- For multiple stores, check each account one by one.The backend does not display multiple accounts together; accounts that received a notice and those that did not are shown separately. Accounts under the same registered entity may affect each other. Amazon'sOfficial statement on multiple selling accountsIt contains a direct statement: accounts should remain in good standing, and a policy issue with one account may affect related accounts.
If an account happens to hover around the threshold, do not bet that it will drop below next month. Triggers are determined on a rolling basis, and dropping below does not mean that obligations already incurred disappear.
Second layer: who the policyholder is determines which links it can cover.
The insured name on the policy must match the registered entity in the backend.
This is the item with the highest rejection rate: the insured is listed as a store name, brand name, or legal representative's personal name, while the registered entity in the backend is another Hong Kong company or a mainland Chinese company, and the certificate will be deemed non-compliant.
Whether several store links can share one policy depends on whether they belong to the same registered entity, not on whether they are operated by the same team.
| Common mismatches in insurance attribution for account matrix setups | ||
| Single entity, single store | Take out one policy under that registered entity, with the insured name exactly matching the backend. | The insured is written as a brand name or personal name. |
| Single entity, multiple stores | One policy covers multiple stores under the same entity, but all stores and sites must be declared at the time of insurance. | Only the one store that received the notice was insured; the others were not declared and are not covered when a claim occurs. |
| Multiple entities, multiple stores | Insure separately by entity, one policy per entity; it is not recommended for multiple entities to share one low-coverage policy. | When several entities pool into one policy, a claim by any entity triggers coverage allocation and underwriting inquiries. |
It is best to use the same entity definition for ownership attribution as for account grouping.
Account grouping is by operations team and policies are by registered entity; if the two tables do not match, extra time will be spent proving link ownership when a claim occurs.
For how to define the grouping fields, you can refer toMulti-account management for Amazon multi-store operations: account grouping, login records, and exception handling processes, binding the four items—entity, site, store, and environment—to the same record.
Third layer: even if these links have not crossed the threshold, it is recommended to proactively insure them.
The third layer is not a compliance requirement; it is a risk pricing issue.
The following four types of links have above-average claim probability and single-claim amounts; waiting for a notice before buying often means running head-on into a sales suspension window:
- Categories involving children and mother-and-baby products: Baby products, children's toys, and children's clothing accessories; claim drivers are strong, and review is stricter.
- Categories involving electrical power, heating, or chemicals: Power banks, small appliances, heating products, cleaning agents, fragrances, and cosmetics; the claim pathways for fire, burns, and skin reactions are clear.
- ASINs for which buyers have filed personal injury or property damage claims: Regardless of whether they are ultimately settled, such listings have already left records on the platform and insurance side, and relisting the same product will receive heightened scrutiny.
- New listings that spend a high budget on traffic immediately after launch: Fast sales ramp-up means the underwriting window is compressed, and there is no buffer once something goes wrong.
The difference between proactively buying insurance and passively waiting for notice is not the premium, but two things: first, you can complete policy inception before the notice deadline without compressing underwriting time; second, the coverage scope is declared by you, rather than reported after the fact. When reporting retroactively after the fact, insurers generally do not provide retroactive coverage for claims that have already occurred.
The three-tier determination proceeds in the order of account, entity, and listing, and the insurance coverage scope is decided only after each tier is confirmed.
What is AIA: it only addresses 'where to buy,' not 'whether to buy.'
Treating AIA as an exemption condition is the most common misconception.
Amazon AIA is an officially integrated insurance channel. Its purpose is to simplify policy issuance and certificate submission, allowing you to obtain a policy that meets the platform's format requirements more quickly through designated insurance providers. It does not change the insurance obligation itself, nor does it automatically cover all store entities under your name.
After issuing a policy through AIA, you still need to verify three things: whether the insured name matches the registered entity in the backend word for word; whether the coverage amount and effective date meet the requirements in the backend notification; and whether the stores and sites declared at the time of insurance are complete. If any one of these does not match, the certificate will be returned, and reissuing after a return usually takes longer than the initial underwriting.
Submission and Effectiveness: Four Things to Prepare in the Backend
- Confirm the trigger status.On the Account Health page, take a screenshot to save the notification content and deadline, and confirm which site and which entity triggered it. Multi-store operators should go through each account one by one, rather than looking only at the first email that arrived in the inbox.
- Determine the entity to be insured.Use the registered entity in the backend as the basis, list all stores and sites under that entity that need to be declared, and create an insurance checklist. If the entity information does not match the registration materials, correct the backend information before applying for insurance.
- Complete policy issuance and verify the key fields.Compare the four items—the insured name, coverage amount, coverage period start and end dates, and covered product scope—one by one against the notification requirements.An effective date later than the notification deadlineis the second-largest reason for returns, second only to name inconsistency.
- Submit the documents in the backend and confirm the status.After submitting, do not immediately switch back to operations. Wait one business day, then return to the Account Health page to confirm whether the status has changed to Approved; if it still shows Pending Review or Rejected, handle it according to the reason for rejection, and do not upload the same file again.
The document submission entry is under the Account Health-related page. After submission, you need to return to that page to confirm the review status.
The three most common pitfalls for multi-store teams
Only handle the one store that received the notification.
Other accounts under the same registered entity may be subject to linked review, which is consistent with Amazon's official statement that 'a policy issue with one account may affect related accounts.' The correct approach is to handle them all at once by entity, not to deal with them one by one based on notifications.
Multiple entities share one insurance policy with a relatively low coverage limit.
Whether the coverage limit is per incident or on an aggregate payout basis directly determines the feasibility of sharing it among multiple entities. Sharing one policy may be considered risk concentration during underwriting; after a claim, the payout is divided among the parties, and the actual amount that can be paid out is far lower than expected.
The insurance information does not match the account grouping or environment attribution.
When a claim occurs, the platform and the insurance company need to confirm 'which entity operates this listing and under which account.' If login environments, payment information, and operation records are mixed, you must rely on records to prove ownership. For why listing ownership must rely on environment and entity records rather than verbal explanations, seeA breakdown of IP, browser fingerprints, payment information, and operation trails for Amazon store anti-association; For the configuration approach to one-to-one mapping between environments and accounts, seeMulti-Account Management Solution.
Frequently Asked Questions
Is the sales threshold assessed per individual store, or calculated by combining all stores?
It is assessed separately based on the account's sales on that marketplace and is not combined across accounts. Each account that receives a notification must meet the insurance requirements independently, and notifications are also issued on a per-account basis.
Can a certificate obtained through Amazon AIA be submitted directly?
It can be submitted, but you still need to manually verify whether the insured's name, coverage amount, and effective date meet the notification requirements. AIA guarantees that the issuance channel is compliant; it does not guarantee that the fields will automatically match the registered entity in your backend.
Can multiple stores under the same entity share a single insurance policy?
Yes, provided that when obtaining the insurance, all stores and marketplaces under that entity are declared, and the policy terms permit coverage of these insured subjects. If only one of them is insured and you want to add others afterward, an endorsement is usually required; whether it can be applied retroactively depends on the policy terms. For how to maintain the list of entities and accounts, refer toAmazon Multi-Account Management Practical Guide.
The new policy hasn't taken effect yet—will the link be restricted?
If you have submitted compliance documents within the notification period and they are under review, you will generally not be restricted immediately; only if the deadline passes and you still have not submitted them, or if the documents are returned and left unaddressed, is there a risk of restricting your selling privileges. The specific handling timeline is subject to the notification in your backend; do not use other people's experience as a substitute for the status shown on your own page.
