How an affiliate scaled to 200 Facebook Ads accounts without bans

this case study is about a single affiliate operator, a nutraceutical and finance lead-gen buyer based out of Southeast Asia, who spent roughly 18 months building out an account infrastructure that could hold 200 live Facebook Ads accounts simultaneously. the goal was not novelty. it was survival. one account getting flagged used to mean a campaign paused, a funnel dead, revenue wiped overnight. at 200 accounts, a single ban was a rounding error.

i’ve been watching this operator’s build-out closely, and parts of it overlap with infrastructure i’ve run myself for e-commerce and app install offers. this is not a blueprint for breaking terms of service. it is a practical account of how serious buyers structure redundancy into their ad operations. every method described here sits in a grey area that Meta tolerates at varying thresholds, depending on enforcement cycles. if you are running one personal account boosting posts for your cafe, none of this applies to you. if you are a media buyer running six-figure monthly ad spend, you’ve probably already thought about most of this.

the headline result: 200 accounts live at peak, roughly 170 active at any given time due to natural churn, and a ban rate of under 4% per month in steady state once the warm-up pipeline was mature. that is a meaningful improvement over the 20-40% monthly churn this operator was seeing before systematising things.

the setup

the core stack was built over about six months before it stabilised. here is what was running:

antidetect browser: AdsPower, on the team plan at around $30 per month for unlimited profiles. each account ran inside its own browser profile with a unique canvas fingerprint, webgl hash, and hardware concurrency value. the operator had evaluated Multilogin but the per-profile pricing model did not scale well beyond 50 accounts. at 200 profiles, AdsPower’s flat team pricing made more sense. for a deeper comparison of antidetect browsers at this scale, the antidetectreview.org/blog has current pricing breakdowns that i’ve found accurate.

proxies: residential rotating proxies from a tier-1 provider, with sticky session support so the same IP stayed assigned to the same account for a 24-hour window. cost at this volume was roughly $400-600 per month depending on usage. mobile residential IPs cost about 40% more but were used selectively for account creation and verification steps, where mobile-origin traffic tends to get less scrutiny from Meta’s risk scoring. see our proxy selection guide for how to evaluate providers at this scale.

virtual payment cards: the operator used a card issuance service to provision unique virtual visa cards for each account cluster. not individual cards per account, but one card per cluster of 3-5 accounts to reduce the spend-to-card ratio that triggers reviews. typical top-up per card: $200-500 before the first charge. this is important. underfunded cards that get declined on the first billing cycle will almost always trigger a review.

account sourcing: a mix of self-warmed accounts (more on this below) and purchased aged accounts from a marketplace supplier in Eastern Europe the operator had vetted over multiple batches. aged account cost ranged from $15 to $60 depending on age, activity history, and whether they had a prior spend history. accounts with prior ad spend, even $5-20, passed initial review much faster.

tracking: Voluum on a custom domain, with server-side conversion postback. direct linking through Meta was avoided where possible because landing page review was a common ban trigger on certain offer categories.

team: two people. one account manager doing daily health checks, one media buyer who touched maybe 20-30 active accounts at any time. the other 140-170 accounts were either warming or in low-spend maintenance mode.

total monthly infrastructure cost at steady state: approximately $1,400-1,800 per month, not counting the account acquisition cost which front-loaded most of the capital requirement.

what worked

structured warm-up with real spend signals. the single biggest factor in survivability was not the proxy setup or the antidetect browser. it was time and legitimate spend. every new account, whether self-created or purchased, went through a 14-21 day warm-up period. day 1-3: nothing, just login activity from the assigned IP. day 4-7: page likes, some organic engagement from a secondary account. day 7-14: boosted posts on a whitelisted page, starting at $2-5 per day. only after that did the account move into a real campaign. accounts that skipped this phase had a ban rate roughly 3x higher in the first 30 days.

geographic and IP consistency. every account had one assigned IP subnet. the operator used sticky sessions specifically so that no account ever logged in from a different city or country within a single session window. Meta’s risk model is sensitive to login location variance, especially on newly created or recently purchased accounts. Meta’s own advertising policies don’t spell this out, but the enforcement pattern is consistent enough that treating geographic consistency as a hard rule paid off.

creative and offer segregation by account tier. the operator split accounts into three tiers. tier 1: clean, aged, high-spend-history accounts used only for the most compliant offers. tier 2: mid-age accounts for standard affiliate offers with minor compliance risk. tier 3: newly warmed accounts used for testing creative, new offers, or anything that historically triggered review. when tier 3 accounts got banned, it didn’t matter. they were expected to churn. tier 1 accounts almost never ran anything that would trigger a manual review.

Business Manager diversification. accounts were not all under a single Business Manager. they were spread across roughly 40 BMs, each holding 3-6 ad accounts. when Meta banned a BM, it typically took the accounts under it. keeping the BM count high and the account-per-BM count low meant a BM ban was a $60-150 loss, not a $1,000+ one. this required more overhead to manage but was worth it.

fast response to policy flags. Meta’s Marketing API surfaces account quality signals that most buyers don’t read. the operator had a lightweight script polling the API daily for any accounts with quality score changes or restriction flags. catching a restriction at the warning stage, before it escalated to a full ban, allowed about 40% of flagged accounts to be saved by pausing, swapping creative, or reducing spend velocity.

what broke

card velocity flagging. at around month four, the operator hit a problem where Meta started flagging clusters of accounts that shared a card issuer’s BIN (bank identification number). the card service being used was issuing cards from two or three BIN ranges, and Meta’s fraud detection had apparently pattern-matched on that. the fix was switching to a card service with a broader BIN spread and adding a manual review step before assigning cards to tier 1 accounts. this cost about two weeks of degraded performance and the loss of roughly 15 accounts.

proxy provider IP contamination. in month seven, one of the residential proxy pools started delivering IPs that had already been flagged by Meta, probably from other buyers on the same pool who ran aggressive campaigns. this showed up as new accounts getting trust-scored low before they ran a single ad. the operator identified this by testing new accounts with a fresh IP source and seeing dramatically better initial trust scores. the fix was switching to a different proxy provider for account creation specifically, while keeping the existing provider for ongoing session management. our proxy rotation guide covers this split-function approach in more detail.

operator burnout from manual monitoring. at 200 accounts, doing health checks manually was not sustainable for two people. the operator was running spreadsheets updated by hand, which meant issues were caught hours or sometimes a day late. the fix was building a simple monitoring dashboard using the Meta Marketing API combined with a Telegram bot that pushed alerts when accounts dropped below a threshold spend level or hit a policy flag. this cut the mean time to detect a problem from 18 hours to under two hours. the dashboard took about three days to build and was the highest-leverage investment in the second half of the build-out.

the numbers

i want to be careful here. i’m not going to publish revenue figures because they depend entirely on the vertical, the offers, and the margin structure of whoever is reading this. what i can share is the infrastructure economics.

total setup cost over 18 months (account sourcing, proxy setup, tools, cards): approximately $28,000-35,000. this is front-loaded because account acquisition is the most expensive phase.

monthly operating cost at steady state (200 accounts, 170 active): $1,400-1,800 infrastructure, plus account replenishment of roughly $300-600 per month to replace natural churn.

account lifetime: tier 1 accounts averaged 8-11 months before a ban or permanent restriction. tier 3 accounts averaged 3-6 weeks. the tiering system meant the expensive assets lasted and the cheap ones absorbed the testing risk.

ban rate at steady state: under 4% per month across the full account pool. in the first six months before the warm-up pipeline matured, it was 12-18% per month. the improvement came almost entirely from discipline in the warm-up process, not from more sophisticated technical tooling.

scaling ratio: for every $1,000 per month in infrastructure cost, the operator could sustain approximately 100-130 active accounts. this is consistent with what i’ve seen in other similar operations.

lessons

infrastructure cost is not the constraint. it’s the warm-up pipeline. the bottleneck is never the proxy or the antidetect browser. it’s the 14-21 days of patience required to create an account that survives. operators who try to shortcut this consistently pay in higher ban rates.

BM diversification is non-negotiable at scale. consolidating accounts under a small number of Business Managers is one of the most common mistakes i see from operators trying to scale. the blast radius of a BM ban is too high. keep BMs small and numerous.

treat accounts like a portfolio with risk tiers, not a uniform pool. not all accounts should run the same offers or the same creative risk level. the tiering approach is not complicated. it just requires discipline.

API monitoring is not optional above 50 accounts. if you are checking account health manually via the Ads Manager UI at scale, you are always behind. the Meta Marketing API gives you programmatic access to account quality signals. use it.

IP contamination is a real risk with shared proxy pools. residential proxies are shared infrastructure. other buyers on the same pool affect your IP reputation. test new IPs before assigning them to your best accounts, and consider using different providers for account creation versus ongoing session maintenance. there’s more on this in the proxy-focused coverage over at proxyscraping.org/blog if you want to go deeper on IP quality evaluation.

the FTC compliance angle is often overlooked. at this scale, many affiliates are running offers that require disclosures under the FTC Endorsement Guides. landing page and ad copy compliance is not just a Meta policy question. getting both right reduces the surface area for creative-triggered bans while also keeping you on the right side of regulatory risk. this is not legal advice; consult a lawyer for your specific situation.

would I do it again

the honest answer is: it depends on the vertical and the margin.

at 200 accounts, you are running a small operations company, not a solo affiliate. you have infrastructure costs, account management overhead, and a constant replenishment pipeline to maintain. if the margin on your offers is thin, this model does not work. the economics only make sense when you have high-margin offers where the cost of account churn is small relative to the value of a live, trusted account.

the approach also requires a particular kind of operator patience. most people who try this bail at month three or four, when the setup costs are real but the account pool isn’t mature enough to generate consistent output. the operator in this case study almost quit at month five. the accounts they had sourced were churning faster than they expected because the warm-up process wasn’t disciplined yet. once they fixed that, everything else followed.

if i were starting this today, i would spend the first three months building nothing but the warm-up pipeline and monitoring infrastructure before scaling the account count. the instinct is to scale accounts first and figure out the operations later. that instinct is wrong. get the operations right at 20 accounts and then scale. you’ll reach 200 with half the capital burned and twice the survivability.

for operators who want to see how this kind of infrastructure compares across different use cases, the multi-account operations guides at /blog/ cover adjacent verticals including e-commerce and app installs where the account management logic is similar even when the offer structure is different.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-22.