Any organisation operating more than a handful of social accounts eventually runs into the same wall. A marketing agency manages profiles for forty clients. A global brand runs separate accounts for twelve markets. A franchise business has a page for every location. A publisher operates accounts for each of its titles. All of these are entirely legitimate, and all of them look — to a platform's automated systems — structurally similar to the account networks those systems are built to detect.
The result is a genuine operational problem. Platforms link accounts through shared signals and take action against clusters they judge inauthentic, and their detection cannot easily distinguish a legitimate agency from an illegitimate network. Losing a client's account to an automated enforcement action is a real business risk, and it happens to organisations doing nothing wrong.
This guide covers how platforms link accounts, what legitimate multi-account operation requires, where the terms-of-service lines actually sit, and how to run this in a way that's both defensible and durable.
Start With the Legitimate Cases
Being clear about what this guide covers, because the same techniques serve very different purposes.
Legitimate multi-account operation includes:
- Agencies managing client accounts. Each client's account is the client's, operated on their behalf with their authorisation.
- Multi-market brand presence. Separate accounts per country or language, which platforms explicitly support and expect.
- Multi-location businesses. Franchise, retail, and hospitality operations with a page per location.
- Multi-brand organisations. A parent company operating distinct accounts per brand.
- Team-based access to shared accounts. Several people managing one account, which is the most common case of all.
- Separation of personal and professional presence. An individual with a business account and a personal one.
What this guide does not cover: creating accounts that misrepresent who is behind them, operating networks of personas to manufacture the appearance of independent support, or evading enforcement against accounts that were removed for cause. These are prohibited by every major platform, they're the reason the detection exists, and the material here is not a workaround for them.
The honest framing: legitimate operators face detection built for illegitimate ones. The goal is to operate in a way that is genuinely authentic and also legible as authentic to automated systems, which are two different things.
How Platforms Link Accounts
Understanding the signals explains why the operational discipline looks the way it does.
Network signals. IP address is the most obvious. Multiple accounts logging in from one address is the classic linkage signal, and it's why this discipline involves proxies at all. Address type matters too — datacenter and hosting ranges are treated as strong negative signals on consumer platforms, since real people don't log in from a server.
Device and browser fingerprint. Screen resolution, installed fonts, canvas and WebGL rendering characteristics, hardware concurrency, audio stack behaviour, timezone, and language settings. Together these are frequently more distinctive than an IP address, and they persist across address changes.
Cookies and local storage. The most direct linkage. Accounts sharing a browser profile are linked immediately and unambiguously.
Behavioural patterns. Activity timing, session rhythm, interaction speed, typing cadence, and the sequence of actions taken. Distinctive patterns repeated across accounts link them, and this signal survives every change of address and fingerprint because it describes the operator rather than the device.
Content signals. Identical or near-identical posts, shared imagery, and coordinated timing. Cross-posting the same content simultaneously across an estate is both a linkage signal and, separately, poor practice for reach.
Graph signals. Accounts that follow the same unusual set of others, interact with each other, or appear in each other's networks.
Registration artefacts. Email domains, phone numbers, recovery details, and registration timing clusters.
The practical implication: the IP address is one signal among many, and probably not the most important. An operation that solves the address problem and leaves everything else shared is still linked. Conversely, a well-separated operation with imperfect address hygiene may be fine.
> Tip: If your operational model relies entirely on IP separation, it isn't a model. Fingerprint, storage, and behavioural separation matter at least as much.
The Right Infrastructure
Static addresses, not rotating ones. This is the single most important and most commonly misunderstood point. Rotating residential proxies are wrong for account work. An account that logs in from three countries in an hour looks nothing like a person, and it's a far stronger negative signal than a slightly imperfect address would be.
One identity, one address, indefinitely. Each account gets a dedicated address held over the long term, building a consistent history with the platform.
ISP (static residential) addresses are usually the right choice. They combine consumer ISP classification with datacenter stability and speed, they don't change, and they're considerably cheaper than mobile. This should be the default and the first thing tested.
Mobile addresses where the platform weights mobile origin heavily, or where ISP addresses are being challenged. Carrier-grade NAT means mobile addresses carry high trust, and mobile-first platforms treat carrier traffic as a positive signal. More expensive, smaller pools, and worth it where the evidence supports it.
Never rotating residential, and never datacenter. The first breaks session consistency; the second is a strong negative signal on consumer platforms.
Geographic matching. The address should be located where the account plausibly operates. A brand's German account operated from a German address is coherent. Operated from a Brazilian one, it isn't.
Don't over-concentrate. Running many accounts behind a single address recreates the linkage pattern the separate addresses were meant to avoid. The safe ratio is one, and stacking is a well-known detection pattern.
Keep a replacement path. Addresses occasionally get flagged. Know your provider's swap policy before you need it, and structure your configuration so replacing an address is a record update rather than a reconfiguration.
Complete Identity Separation
The address is one layer. A coherent separation model covers all of them.
A dedicated browser profile per account. Separate cookies, local storage, cache, and session data, with no sharing whatsoever. Anti-detect browsers exist for this purpose and are the standard tool, though separate browser profiles or containers work for smaller operations.
A consistent fingerprint per profile. Not a random one per session — a stable, plausible fingerprint that persists. A device whose screen resolution changes weekly is its own anomaly.
Coherent locale. Address geography, browser locale, timezone, language preferences, and the content the account engages with should all describe a consistent picture.
Separate registration details where the account structure genuinely calls for it — distinct emails, distinct recovery paths.
Never cross-contaminate. Don't log into account A from account B's profile, even once. A single cross-login links them permanently.
Document the mapping. Account, address, profile, geography, and responsible team member, in persisted storage. This matters operationally and it matters when someone leaves and their successor inherits the estate.
Use platform-native tools first. This is the point most often missed. Every major platform offers business tools designed for exactly this: business manager products that let multiple people access multiple accounts through their own credentials, without any of the separation machinery above. Where the platform provides an official mechanism, using it is both safer and easier than working around it.
Platform-Native Approaches
Before building separation infrastructure, exhaust the official routes, which handle most legitimate cases entirely.
Business and brand management platforms. Major platforms offer centralised management where an organisation holds accounts and grants individual people access under their own logins. No shared credentials, no shared sessions, no linkage problem, and full audit trails.
Partner and agency access mechanisms. Platforms provide structured ways for agencies to be granted access to client accounts. This is the correct answer for agency work and it removes almost the entire problem this guide describes.
Official APIs. Publishing, scheduling, and analytics through documented APIs is sanctioned, rate-limited transparently, and doesn't involve browser sessions at all.
Approved third-party management tools. Scheduling and engagement platforms that integrate through official APIs operate within the rules and handle multi-account work as a designed feature.
Location and multi-market structures. Platforms support parent-child page structures for multi-location businesses explicitly, which is designed for exactly this case.
When the official route doesn't cover it: genuinely separate operations, markets where a platform's business tooling is unavailable, or workflows the API doesn't expose. That's the residual case where the separation infrastructure in this guide applies, and it's smaller than most teams assume before they check.
Governance and Access Control
The organisational half of the problem, and the one that causes more actual account losses than platform enforcement does.
Ownership must be explicit. For every account: who owns it legally, who administers it, who has publishing rights, and who holds recovery access. Agencies in particular should establish that client accounts belong to the client, documented in the contract, with the agency holding delegated access rather than ownership.
Never share credentials. Platform business tooling exists precisely so individuals log in as themselves. Where credentials must be held, a password manager with per-account entries and role-based access, never a shared document.
Recovery access is the critical asset. The email address and phone number attached to an account determine who can recover it. If those belong to a departed employee or a former agency, the account is at risk. Audit recovery details across the estate and make them organisational rather than personal.
Offboarding must be a process. When someone leaves, their access is revoked across every account, credentials are rotated, and any recovery details pointing at them are changed. This is routinely missed, and it's how organisations lose accounts to people who no longer work there.
Maintain an account register. Every account, its platform, its purpose, its owner, its administrators, its associated address and profile, its recovery details, and its authorisation basis. This is dull and it's the difference between managing an estate and hoping.
Audit periodically. Accounts accumulate. Dormant accounts with stale credentials and forgotten recovery details are both a security exposure and an enforcement liability.
Plan for account loss. It happens, sometimes without cause. Know in advance what recovery looks like, what the client communication is, and whether content is backed up outside the platform.
Multi-Market and Agency Structures
Two specific structures worth addressing directly, since they account for most legitimate multi-account operation.
Multi-market brand presence. Platforms generally support this well and expect it. Practical points:
- Use the platform's own structure for market-specific pages where one exists, rather than creating unconnected accounts
- Match each account's operating geography to its market — address, locale, timezone, and the language of engagement
- Expect local teams to operate local accounts, which is both more authentic and simpler than centralised operation through separation infrastructure
- Keep brand consistency in content without making posts identical across markets, since identical cross-posting is both a linkage signal and poor localisation
Agency management of client accounts. The case where official tooling matters most:
- Use the platform's partner or agency access mechanism. This is the correct answer and it removes almost the entire linkage problem
- Access should be granted by the client to the agency, revocably, with the client retaining ownership
- Individual team members log in as themselves under that delegated access
- Document the authorisation in the client contract, including what happens to access at termination
- Where a platform genuinely lacks agency tooling, the separation infrastructure applies — but check first, because coverage is better than most agencies assume
- Never hold client credentials as the primary access method if a delegation mechanism exists
The recurring theme: the more your structure resembles what the platform designed for, the less operational machinery you need and the lower your enforcement risk. Separation infrastructure is a workaround for gaps, not a default architecture.
Operational Discipline
Warm accounts gradually. New accounts performing high-volume activity immediately are the clearest possible signal. Ordinary, gradual activity over days establishes a normal baseline.
Behave at human rhythms. Real people act irregularly, take breaks, don't operate at 4am local time every night, and don't perform identical action sequences repeatedly. Timing regularity is a linkage signal independent of everything else.
Match activity to the account's stated identity. A local business account engaging exclusively with content from another continent is incoherent.
Keep credentials properly managed. A password manager with per-account entries, not a shared spreadsheet. Credential hygiene is both security and operational practice.
Enable multi-factor authentication, and manage the second factor per account. Recovery access is what saves an account when a verification challenge appears.
Retain a manual access path. When a platform issues a verification challenge, the ability for a human to log in through the same address and complete it is frequently what preserves the account. That only works with stable, dedicated addresses.
Never reuse a flagged address. If a platform has associated an address with an enforcement action, placing another account behind it links them.
Monitor account health. Restrictions, reach changes, and verification prompts are early signals. Discovering a problem when a client asks about it is late.
Separate risk classes. Read-only monitoring and active publishing carry different risk. Keep them structurally separate where practical.
Working With Client Accounts
Agencies carry the sharpest version of this problem, because the account at risk belongs to someone else and the relationship depends on it surviving.
Establish ownership in writing before anything else. The client owns the account. The agency holds delegated access. What happens to that access at termination should be specified, along with who holds recovery details and how a handover works. This protects both parties and it prevents the most common agency-client dispute in this space.
Insist on delegated access rather than credentials. Where a platform offers partner or agency access, use it. Holding a client's password is worse for everyone: no audit trail, no granular revocation, and a security exposure that becomes the agency's liability if anything happens.
Document the authorisation per account. Who at the client authorised the access, when, and for what scope. If a platform ever questions the relationship, this is what answers it.
Never mix client estates. One client's accounts should share no addresses, no profiles, and no browser state with another's. Beyond the linkage risk, cross-contamination between clients is a confidentiality problem.
Be candid about enforcement risk. Clients should understand that platform enforcement is automated, occasionally wrong, and not fully controllable. Discovering this during an incident is much worse than discussing it during onboarding.
Back up client content. Posts, assets, and audience data where the platform permits export. If an account is lost, what you can hand back matters.
Plan the handover. When a relationship ends, access is transferred cleanly, recovery details are updated to the client, and the agency's addresses and profiles are retired from that estate rather than reused for the next client.
Keep the client informed of health. Restrictions, reach anomalies, and verification prompts should reach the client from you, before they notice independently.
Handling Restrictions and Recovery
Accounts get restricted, sometimes wrongly, and how you respond in the first hours matters considerably.
Understand what happened. Restrictions vary enormously: a temporary action limit, a verification requirement, a content removal, a feature restriction, a suspension, or a permanent disablement. These have different causes and different remedies, and treating them identically wastes the recovery window.
Complete verification challenges promptly and manually. Most restrictions are verification prompts rather than enforcement. A human logging in from the account's usual address and completing the challenge resolves them. This is the practical argument for stable dedicated addresses that most clearly pays for itself.
Don't panic-create a replacement. Creating a new account to replace a restricted one, especially behind the same address or profile, links the two and frequently extends the enforcement rather than working around it.
Appeal through the official process, with specifics. Generic appeals fail. An appeal naming the legitimate business, the authorisation, and the account's purpose does better than one asserting the action was wrong.
Preserve evidence of legitimacy. Business registration, the client authorisation, the account's operating history. Appeals that come with documentation are treated differently from ones that don't.
Expect it to be slow and opaque. Appeals processes are automated at the first tier, and response times are measured in days or weeks. Set client expectations accordingly rather than promising a resolution you don't control.
Look for a cause. Sometimes there is one — a content policy breach, a sudden activity change, a linkage event. Identifying it prevents recurrence, and "we don't know why" usually means nobody looked.
Check the rest of the estate. Enforcement can cascade across linked accounts. If one account is actioned, review the others before they follow.
Have content backed up outside the platform. If recovery fails, what's lost should be the reach, not the archive.
Terms of Service: The Honest Position
This deserves directness rather than evasion, because the risk is real and frequently understated.
What platforms permit: operating multiple accounts for genuinely distinct entities, brands, markets, or locations. Agency management of client accounts through sanctioned mechanisms. Automation through official APIs within documented limits.
What platforms prohibit: accounts that misrepresent who operates them, coordinated networks designed to appear independent, evading enforcement, and automation through browser session manipulation rather than sanctioned interfaces.
Where the grey area sits: using browser-based access with separation infrastructure for legitimate accounts, because a platform's official tooling doesn't cover your case. This is not clearly prohibited in most terms, it's not clearly sanctioned, and it will be judged by the platform's automated systems on how it looks rather than on your intent.
The risks, stated plainly:
- Enforcement is automated, and appeals processes are slow, opaque, and frequently unsuccessful
- Losing a client's account is a commercial and relationship problem regardless of fault
- Linkage means enforcement can cascade across an estate rather than affecting one account
- Rules change, and a practice that was tolerated becomes actioned
- There is no reliable way to confirm compliance in advance
The sensible posture: use official mechanisms wherever they exist, keep the residual browser-based operation genuinely authentic, maintain documentation of the legitimate business relationship behind every account, and understand that platform enforcement is a business risk to be managed rather than eliminated.
Monitoring the Estate
An account estate degrades quietly. A few things worth watching continuously rather than discovering reactively.
Access health. Whether each account is reachable, whether credentials still work, and whether any verification challenges are outstanding. A weekly automated check across the estate catches problems before they compound.
Restriction and warning signals. Platform notifications, feature restrictions, and reach anomalies. These generally arrive before a serious enforcement action and are the window in which something can be done.
Recovery detail drift. Whether recovery emails and phone numbers still point where they should. This changes when people leave and nobody updates it, and it's discovered at the worst possible moment.
Address health. Whether any account's address has been flagged, and whether replacements are needed. Your provider's swap policy is the remedy, and knowing its limits in advance matters.
Profile integrity. That browser profiles remain separated and no cross-contamination has occurred. A single accidental cross-login is worth detecting immediately.
Dormancy. Accounts with no activity for extended periods, which should either be revived deliberately or closed. Dormant accounts carry cost and risk with no offsetting value.
Authorisation currency. For agency estates, whether the documented authorisation for each account is still current and whether the client relationship still exists.
Aggregate anomalies. Several accounts showing restrictions in a short window suggests a linkage event or a platform policy change rather than coincidence, and it warrants investigation before more follow.
Cost and Scale
Multi-account infrastructure costs more per account than people expect, and understanding the shape helps decide whether to build it at all.
The per-account cost stack:
- A static address, ISP or mobile, at one per account
- A browser profile, which on commercial anti-detect platforms is typically licensed per profile
- Operational time, which is the largest cost and the one nobody budgets
The comparison worth running: cost per account per month against the value of that account. If losing an account would cost substantially more than a year of dedicated infrastructure, the conservative configuration is obviously correct. If an account is marginal, the honest question is whether it should exist at all.
Why official tooling wins economically. Platform business manager access costs nothing, requires no addresses, no profiles, and no separation discipline. Every account you can move into official tooling removes an entire per-account cost line. This is the strongest argument for checking the official route, ahead of the risk argument.
Scale changes the calculus. At five accounts, manual operation with separate profiles is manageable. At fifty, you need tooling, documented procedures, and someone whose job includes maintaining the estate. At two hundred, the operational overhead is a function rather than a task, and the case for consolidating into official mechanisms becomes overwhelming.
Prune the estate. Most organisations carry accounts that serve no current purpose. Each one costs infrastructure, carries enforcement risk, and represents a security exposure through stale recovery details. Closing them is usually the cheapest improvement available.
Track the cost per active account, not the total. An estate where a third of accounts are dormant is paying three times what its active presence costs.
Common Mistakes
Building separation infrastructure before checking the official route. The most common and most wasteful error. Platform business tooling handles a large majority of legitimate multi-account cases with no linkage risk at all.
Using rotating residential proxies. Wrong tool. Rotation breaks session consistency, and an account appearing from multiple countries is a stronger negative signal than almost anything else.
Using datacenter addresses. Consumer platforms treat hosting ranges as a strong negative signal, because real people don't log in from servers.
Solving only the IP problem. Fingerprint, cookies, storage, and behaviour link accounts independently of address. An operation with perfect address separation and a shared browser profile is linked immediately.
Stacking accounts behind one address. Recreates the exact pattern the separation was meant to avoid.
Cross-logging even once. A single login to account A from account B's profile links them permanently and irreversibly.
Random fingerprints per session. A device whose characteristics change weekly is its own anomaly. Fingerprints should be stable per profile.
Immediate high-volume activity on new accounts. The clearest possible signal, and entirely avoidable with a gradual ramp.
Personal recovery details on organisational accounts. The single most common cause of permanent account loss, and it surfaces months after the person leaves.
Shared credential documents. Security exposure, no audit trail, and no way to revoke individual access.
No account register. Estates grow, people leave, and nobody knows what exists or who controls it.
Reusing a flagged address for a replacement account. Links the new account to the enforcement action against the old one.
Assuming enforcement won't happen because you're legitimate. Enforcement is automated and imperfect, and legitimacy is not a defence against a classifier.
A Realistic Build Sequence
Phase one — audit what you actually have. Every account, platform, owner, administrator, recovery detail, and authorisation basis. Most organisations discover accounts nobody remembered and recovery details pointing at former employees.
Phase two — check platform-native tooling for every case. Business manager, partner access, API publishing, parent-child location structures. Move everything that fits into the official mechanism. This will resolve most of your estate.
Phase three — fix governance. Ownership documented, recovery details organisational, credentials in a manager with role-based access, offboarding process defined. This prevents more account losses than any technical measure.
Phase four — identify the genuine residual. The accounts that official tooling doesn't cover. This set is usually much smaller than the initial assumption.
Phase five — build separation properly for the residual. Static addresses one per account, dedicated browser profiles, stable fingerprints, coherent geography, documented mapping.
Phase six — establish operational rhythm. Warm-up procedures for new accounts, human-plausible activity patterns, manual access paths for verification challenges.
Phase seven — monitor account health. Restrictions, reach anomalies, and verification prompts as early signals rather than as client complaints.
Phase eight — plan for loss. Recovery procedures, content backups outside the platform, and client communication templates. Accounts are lost sometimes, and having thought about it in advance is the difference between an incident and a crisis.
Phases one through three cost almost nothing and prevent most real-world account losses. Phase five is what people start with, and it addresses a smaller share of the actual risk than they expect.
When Not to Build This
A short section, because it's the advice most likely to save a reader real money and risk.
If every account fits in platform business tooling, you need none of the separation infrastructure. Move them and stop reading.
If the accounts are genuinely operated by different people in different places, that separation already exists naturally and is more convincing than anything you could construct. A local team operating a local account from their own office is authentic in a way that centralised operation through proxies is only simulating.
If the estate is small. Under about ten accounts, ordinary browser profiles and the platform's own access mechanisms usually suffice, and the operational overhead of a full separation stack exceeds its benefit.
If the accounts don't need to be separate. Consolidating several thin accounts into one substantial presence frequently produces better reach and removes the problem entirely. Estates accumulate accounts that exist because someone created them, not because the strategy requires them.
If you can't articulate the legitimate business behind each account, that's a signal worth taking seriously rather than engineering around. Every account should map to a real entity, brand, market, or location with someone accountable for it.
If the driver is scale rather than structure. Wanting more accounts to reach more people is not the same as needing separate accounts for separate entities, and platforms are specifically built to detect the former.
The honest summary: this infrastructure exists to serve legitimate operations that platform tooling doesn't cover. That's a real category and a smaller one than the market for the tooling suggests.
Legal and Ethical Considerations
- Terms of service are contracts. Breach carries account loss and commercial consequences, and in some circumstances more.
- Authorisation matters. Operating an account on someone else's behalf requires their genuine authorisation, documented. This protects you as much as them.
- Data protection law applies to customer data handled through social accounts, including messages and profile data.
- Disclosure obligations exist in many jurisdictions for advertising and endorsement, and they apply to social content.
- Impersonation is a legal matter, not just a policy one, in many places.
- Don't manufacture the appearance of independent voices. Beyond platform rules, this runs into consumer protection and advertising regulation in a growing number of jurisdictions.
- Employment and access considerations. Who holds credentials, what happens when they leave, and how access is revoked are governance questions worth settling before they're urgent.
Not legal advice, and jurisdictions differ. Agencies handling client accounts should have the authorisation and liability position settled in the client contract.
Frequently Asked Questions
Can I run multiple accounts legitimately?
Yes, for genuinely distinct entities, brands, markets, or locations. Platforms expect this and provide official tooling for it. What's prohibited is misrepresenting who operates an account.
Should I use rotating residential proxies?
No. Rotation breaks session consistency and an account logging in from multiple countries is a strong negative signal. Static addresses — ISP or mobile — are what this work needs.
How many accounts per address?
One, as the safe default. Stacking accounts behind a single address recreates exactly the linkage you're trying to avoid.
ISP or mobile addresses?
Test ISP first — cheaper, faster, and sufficient on many platforms. Escalate to mobile where the platform weights carrier origin heavily or where ISP addresses are being challenged.
Do I need an anti-detect browser?
For genuinely separate browser-based operation, some form of profile isolation is necessary. Whether that needs a specialist tool or ordinary browser profiles depends on scale and on the platform's fingerprinting sophistication.
What if I just use the platform's business tools?
Then most of this guide doesn't apply to you, which is the ideal outcome. Official tooling handles multi-account access without linkage risk and should always be the first option checked.
How do I handle a team where several people manage one account?
Use the platform's business tooling, which is designed for exactly this — each person logs in as themselves under delegated access. Shared credentials for a single account is the worst configuration available: no audit trail, no granular revocation, and a linkage risk if those people also access other accounts.
Does using a VPN work instead of proxies?
Poorly. A commercial VPN gives you shared endpoints used by many people, on ranges that platforms frequently treat with suspicion, with no per-account separation. It solves none of the actual problem and introduces a shared-address linkage risk of its own.
What happens if an account gets restricted?
Appeal through the platform's process, retain the manual access path so verification can be completed, and don't create a replacement account behind the same address. Recovery is more likely than most people expect, and it's slow.
Is this all worth the effort?
Often not. Teams frequently build elaborate separation infrastructure for cases the platform's own business manager would have handled. Check the official route first.
Getting the Infrastructure Right
Where official platform tooling genuinely doesn't cover your case, the infrastructure requirement is stable addresses rather than rotating ones. ProxyScrape's ISP proxies provide static residential-classified addresses on datacenter infrastructure, which is the combination account work needs — consumer ISP classification that platforms trust, held indefinitely so an account builds consistent history, without the rotation that makes residential pools unsuitable here. For platforms that weight carrier origin heavily, or where ISP addresses are being challenged, their mobile proxies route through 3G, 4G, and 5G networks where carrier-grade NAT gives the highest trust available. Their social media account management documentation covers the setup, and note that their rotating residential pool — the right tool for most scraping — is the wrong one for this particular job.
→ Compare static address options for multi-account operation
The most useful thing in this guide is the recommendation to check the platform's own business tooling before building anything, because it resolves a surprising proportion of cases entirely. For what remains, the discipline is unglamorous: stable dedicated addresses rather than rotating ones, complete profile separation, coherent geography, human rhythms, and documented authorisation behind every account you touch. Platform enforcement is automated and imperfect, it will occasionally act against operations doing nothing wrong, and the operators who weather that are the ones who kept each account genuinely separate and could demonstrate the legitimate relationship behind it.