Store A's Fast Handover Rate falls below the target line for two consecutive weeks, and on the third day you see a violation notice in Store B's backend. The two events happen back-to-back, and the first reaction is almost certainly “we've been hit by cross-store spillover.” But when you stretch out the timeline, this “back-to-back” has at least three possible causes: Store B has its own fulfillment issues, the two stores are classified by the platform as the same controlling entity and handled on a consolidated entity basis, or there is simply a time lag in notice issuance.
To determine which one it is, you first need to separate three terms: FHR is a fulfillment metric, penalty points are a record of violation points, and cross-store spillover is not an official term in the platform's rules, but a description of the phenomenon in which penalty points from one store transmit to another. Below, we break this down layer by layer along the chain of “how FHR below target becomes penalty points, and how penalty points cross stores.”
FHR, penalty points, and cross-store spillover: the real relationship among the three terms in the backend
The Fast Handover Rate (FHR) measures the proportion of parcels you hand over to the logistics provider within the required time. It is only a number in itself, not a penalty. Penalty points are the vehicle of the penalty: the platform converts various types of violations into points, and accumulation to different tiers corresponds to restrictions of different severity. If FHR remains below the target value for a long time, it is classified as a fulfillment-related violation and converted into penalty points.
The relationship among the three is one-way:FHR below target → triggers fulfillment-related penalty points → penalty points accrue at the store level → after reaching a tier, that store is restricted. Cross-store transmission occurs only before the last step, and it must first have one prerequisite—the platform determines that these stores belong to the same controlling entity.
In other words, an FHR failure by itself will not result in point deductions for another store; what truly crosses stores is the conclusion of 'entity determination.' So the question is not 'will FHR lead to joint liability,' but 'how many violations can your multi-store structure withstand under the platform's determination logic?'
How Shopee's penalty point system deducts points: Which type of penalty does FHR non-compliance trigger?
Target lines, assessment windows, and point-deduction cadence are not uniform across sites, and the fulfillment chains for cross-border stores and local stores also differ—cross-border stores must go through first-leg and transit warehouses, while local stores ship from local warehouses. Therefore, there is no single set of numbers that applies to all stores; the structure below is used to determine direction. For specific thresholds and cycles, please refer to the policy page for that site in Seller Center, the notification you received, and Shopee Official Help Centershall prevail.
| Item | Actual situation | Impact on multiple stores |
|---|---|---|
| Metric attribution | Fulfillment metrics and penalty points are both recorded on an individual store ID, not on the business license. | The default result of a single-store violation is that only that store is affected. |
| Assessment cycle | Counted on a rolling weekly basis and converted into penalty points according to site rules; cleared according to the rules after the cycle ends | For stores on different sites under the same entity, trigger times are staggered, making it look like there is 'no joint liability' |
| Trigger conditions | Usually requires being continuously below the target value, or the order volume below the target value reaching a certain scale | A single-day occasional fluctuation generally will not result in immediate point deductions; risk is amplified only when multiple stores cross the line at the same time |
| Accumulation method | Penalty points accumulate within the cycle; the higher the tier, the heavier the restrictions | What gets cleared is the score; historical violation records usually remain in the store profile |
| Cross-border vs local | For cross-border stores, timeliness is calculated from order creation to receipt at the transit warehouse; for local stores, it starts from dispatch out of the local warehouse | Using cross-border store standards to judge whether a local store meets the target will skew the conclusion |
The overall differences between these two types of stores in fulfillment, capital, and environment go beyond this one point; for referenceNine differences between running Shopee local stores and cross-border storesFirst build the framework, then come back to judge the penalty point criteria.
What a store loses in turn as penalty points accumulate to different tiers
The order basically goes from the traffic side to the eligibility side, and then to the account side. Details vary by site, but the direction is consistent: the further you go, the higher the cost of recovery.
- Traffic downranking——Search ranking and recommendation slot weights are lowered, order volume falls, but there is no obvious error in the backend, and many people still cannot identify the cause at this stage.
- Marketing restrictions——Registration entries for flash sales, coupons, and platform mega-promotions are locked, and the first things taken away are the means of acquiring new customers and clearing inventory.
- Eligibility revocation——Identity-based benefits such as Preferred Seller, Mall Seller, and free-shipping subsidies are revoked, and conversion rates will drop a notch along with them.
- Funding-side tightening——Settlement cycles are extended, withdrawal reviews become stricter, and cash flow runs into problems earlier than order volume does.
- Store suspension—Products are delisted and new listings are blocked; at this tier, recovery usually requires an appeal.
To determine which tier you are currently in, don't guess—go straight to the Account Health and Violation Records page in Seller Central.
To determine whether association-based enforcement applies, the platform looks at these four layers of variables.
When the platform determines whether several stores belong to the same controller, it does not look only at FHR or only at IP. It cross-checks four layers of variables; the more layers overlap, the higher the probability they will be judged as the same entity.
- Entity information layer—Business license, legal representative identity, store registration email and phone number, and return address.
- Fund flow layer—Entity behind the receiving account, withdrawal bank card, and tax information.
- Environment and network layer——Browser fingerprints (time zone, language, fonts, Canvas/WebGL, and other detectable signals), device characteristics, and the attribution and reuse records of login IPs.
- Behavioral trail layer——Sub-account cross-authorization, customer service script templates, overlap between product main images and detail pages, and listing/delisting timing patterns.
Changing only the IP while the entity information and payout account remain completely identical is a typical case of “changing one layer and leaving three layers.” As for which signals are collected in each of these four layers, you can refer towhich dimensions platforms typically look at when determining whether multiple accounts belong to the same person, and the judgment logic is consistent across different platforms.
Under the same entity, if Store A's FHR does not meet the standard, will it carry over to Store B? Three scenarios
| Scenario | Structural characteristics | Transmission probability | Typical manifestation |
|---|---|---|---|
| One: Completely independent | Different licenses or different legal entities, with payment collection, browser environments, and login IPs each independent. | Low | Store A is restricted due to a point deduction, while Store B receives no notification. |
| II: Same entity, environment isolation | Same license or same legal entity, but payment collection accounts, browser environments, and IPs are separate. | Medium | Generally, points are not deducted directly; when a risk flag appears at the entity level, Store B may be required to provide additional verification. |
| III: Same entity and shared environment | Same license, shared payment collection account, same browser or same IP for login. | High | After Store A is restricted, Store B experiences throttling, verification, or similar penalties within days to weeks. |
The difference between the second and third scenarios is not 'whether there is a connection,' but 'whether the connection evidence is sufficient to be automatically triggered.' Stores under the same entity but with isolated environments often only surface during manual review or periodic risk control audits, so the manifestation is delay, not absence.
In the third scenario, the first thing to go wrong is usually not the IP but the payment chain—after the receiving entity, account, withdrawal card, and tax information are cross-referenced, multiple stores will be directly attributed to the same controller. For the specific sequence of consequences of this chain, refer toWhat happens when several stores share one receiving account.
Self-check: Has your store already been determined to be linked?
Don't wait for a notification. Check each of the following items one by one; if two or more appear, you should treat it as "already linked".
- Does the backend notification point to the store name, or to the business license number, legal representative's name, or entity name;
- Whether sub-accounts use the same email address or mobile phone number to be authorized to multiple stores at the same time;
- Whether the receiving account, withdrawal bank card, and tax information overlap across stores;
- Whether multiple stores have been logged into from the same browser environment or the same IP, and whether the login times overlap;
- Whether product titles, main images, detail pages, and automated customer service replies are highly similar;
- Whether there has been a timing correspondence such as "a new store has just opened and the old store receives a verification request".
Isolation configuration: If you don't want to be implicated, to what extent should each layer be separated?
Isolation is not about replacing everything, but about distinguishing which layers can be shared and which layers must have one set per store.
- Entity layer: Separate it if possible. If it cannot be separated, you must accept the risk exposure at the entity layer—as long as the license is the same, the platform can still attribute the two stores to the same controller. In this case, at least ensure that each store's registered email, phone number, and return address are different.
- Funding layer: One receiving account per store is the bottom line. This layer carries the highest weight in multi-store association determinations; sharing it is equivalent to voluntarily providing evidence.
- Environment layer: One independent browser profile per store; Cookies, Local Storage, cache, and fingerprint parameters are not shared. Opening incognito mode in the same window to switch stores does not count as isolation; incognito only clears local records and does not change fingerprint characteristics.
- Network layer: One fixed egress IP per store; its location must be consistent with the store site and daily login habits, avoiding cross-region jumps within a short period of time.
- Behavior layer: Authorize sub-accounts by store rather than by person; differentiate customer service templates and product assets; avoid multiple stores performing exactly the same operations within a few minutes.
What can be shared is office equipment, personnel, and the ERP account system, provided that API authorization is differentiated by store. What must be one set per store is the receiving account, browser environment, login IP, and sub-account permissions. For the complete isolation sequence and group naming method of a multi-store matrix, refer toSoutheast Asia Local Store Matrix Practical Handbook (Shopee / Lazada); for the environment switching specifications when managing multiple stores on one machine in daily work, seeMulti-Account Management.
Frequently Asked Questions
Are FHR point deductions counted against the business license or the store?
They are recorded against the store. Fulfillment data and penalty points are both attached to a single store ID, and the business license is only one layer of the entity information. Therefore, penalty points for Store A under the same license will not automatically appear in Store B's violation record unless the platform has already determined that both stores belong to the same entity.
If a receiving account is shared and only one store fails to meet the FHR standard, will the other store have points deducted?
Usually, points will not be deducted directly, but the risk level will change. A shared receiving account is itself evidence of association; once the stores are determined to be the same entity, Store A's fulfillment violation will become a risk record at the entity level, and Store B will be more likely to be asked to provide additional information or enter manual review. This often manifests as verification rather than point deduction.
After penalty points are reset to zero, will the joint-liability record be retained?
What is reset to zero is the penalty point number, not the history. Violation records and association determination results generally remain in the store profile and may be retrieved again in subsequent reviews, event registrations, or account rechecks. So relying on 'waiting for the reset' to solve the problem usually does not work.
If multiple stores are logged in from the same computer but different IPs, will failing to meet FHR standards trigger joint liability?
IP is only one item in the environment layer. The same computer means signals such as device characteristics, browser fingerprints, fonts, and time zones may be shared; combined with overlapping entities or payment receiving accounts, an association determination can still be made. Whether it propagates depends on the degree of overlap across the four layers, not on whether the IP has been changed.
Are the FHR penalty point rules the same for cross-border stores and local stores?
No. The timeliness chain for cross-border stores includes first-leg shipping and transit warehouses, while local stores are calculated starting from shipment out of the local warehouse; the target value definitions and assessment windows on the two sides are not interchangeable. To determine whether standards are met, check the corresponding policy page according to the store's site and store type; do not estimate using the standards for the other type of store.
