Local entities and bank accounts

Local Entities and Bank Accounts International payment expansion produces a surprisingly persistent piece of bad advice: "You'll need a company and bank account in every country you enter." Sometimes a local entity matters. Sometimes a domestic bank account matters. Sometimes both become necessary for the payment structure the merchant wants. And sometimes a merchant can serve a market using its existing foreign entity, a global PSP, cross-border settlement, and provider-managed access to local payment infrastructure. The mistake is treating four separate decisions as though they were one: local incorporation local acquiring local bank account local settlement They interact, but they are not synonyms. Current provider infrastructure makes the distinction visible. Checkout.com, for example, markets domestic acquiring across multiple markets through one global platform, illustrating how a provider can supply part of the local acquiring infrastructure rather than requiring a merchant to build a direct acquiring relationship in every country itself. Whether a particular foreign merchant is eligible for a given domestic acquiring route still depends on the market, provider, acquiring setup, merchant, and applicable rules. For expansion teams, the better question is therefore not: "Do we need a local entity?" Start one level earlier: "What payment, acquiring, and settlement model do we want—and what is the minimum legal and banking footprint required to support it?"

Local entity and local bank account are different decisions A local legal entity means the merchant has established a company or other qualifying legal presence in the target jurisdiction. A local bank account means the merchant has an account at a bank or eligible financial institution in the relevant market or banking area. Neither automatically proves the other is required. A merchant may encounter a structure in which: * a local entity is needed but settlement can occur elsewhere; * a local bank account is required for a particular payout arrangement; * an existing foreign entity can process while receiving cross-border settlement; * provider infrastructure enables domestic processing without the merchant independently building every domestic payment relationship; or * a fully local entity-and-bank structure is both required and economically sensible. The dependencies have to be tested individually. That matters because bank location, payout currency and acquiring geography can each affect settlement differently. Adyen's current settlement documentation, for example, says settlement-currency options depend on acquiring region and payment method, while payout mechanics depend partly on the location of the recipient bank account. It distinguishes local payouts through domestic rails from cross-border payouts and identifies currencies for which payout is limited to qualifying local accounts. So this implication is unsafe:

We acquired locally → therefore we must settle locally → therefore we need a local bank account → therefore we need a local company. Each arrow must be verified. Work backward from acquiring and settlement The legal-entity decision is easier when payments teams stop beginning with corporate structure. Start with the payment flow. 1. Which payment methods do customers need? Some payment methods can be made available to international merchants through a global payment provider. Others have eligibility, acquiring, settlement, merchant-registration, banking, or market-specific conditions. Even apparently local banking infrastructure does not always require the merchant to maintain its own bank account in the customer's country. Stripe's current cross-border bank-transfer documentation, for example, describes configurations in which eligible businesses can present customers with local bank-transfer instructions in another supported country without maintaining a corresponding account setup there themselves. That is a Stripe-specific implementation—not proof that every local payment method can be accessed internationally. It does demonstrate the architectural principle: customer access to local rails and merchant ownership of local banking infrastructure are separate questions. For a deeper market-by-market analysis, see how to accept payments without local incorporation. 2. What acquiring model is required? Determine whether the target structure is: * cross-border acquiring;

* provider-enabled domestic/local acquiring; * a direct domestic acquiring relationship; or * some combination based on card, market, payment method, entity or routing strategy. Do not assume that "local acquiring" necessarily describes the merchant's corporate location. It primarily describes the acquiring arrangement. A global PSP may itself hold acquiring relationships or licenses that support domestic processing in particular markets. Checkout.com's current acquiring materials, for example, describe direct acquiring operations across several regions and domestic processing in multiple countries through its platform. The next question is merchant eligibility for the particular acquiring route. That is where entity requirements may enter. For the deeper acquiring decision, see accessing local acquiring without incorporating and when a merchant needs a local entity. 3. Where can settlement go? Payment acceptance and merchant payout are another pair of separate systems. The customer may: pay locally while the merchant: settles internationally. Or the merchant may process through one acquiring structure while maintaining several settlement accounts and currencies.

The merchant therefore needs to ask: Where are funds collected? In what currency are they held or converted? Where can they be paid out? Which entity owns the receiving account? Does that entity match the merchant relationship being processed? Checkout.com's current bank-account procedures illustrate the last point particularly well: when a settlement account belongs to a different entity, Checkout.com says it may request justification for that relationship. A local bank account is therefore not simply a treasury detail. It can become part of the verified legal and settlement architecture. Three common market-entry structures Rather than asking whether international merchants "need local entities," compare the actual operating models. Model A — Foreign merchant + global PSP Customer in Market B ↓ Existing merchant entity in Market A ↓ Global PSP/payment infrastructure ↓ Settlement to merchant's existing banking structure This is the lightest-footprint model conceptually. The merchant does not create a new company merely because customers live in another country. The payment provider handles whatever international or local infrastructure its product and acquiring arrangements permit. Potential advantages: * less corporate administration; * fewer legal entities; * fewer banking relationships; * simpler treasury; * faster structural setup. Potential limitations: * some local acquiring routes may not be accessible; * some payment methods may impose different merchant-eligibility conditions;

* settlement choices may be narrower; * foreign processing or FX economics may differ; * tax, regulatory or licensing questions still have to be assessed separately. The key point is that accepting customers in another market does not by itself establish that local incorporation is required. The merchant must test the specific payment model. For the detailed decision, see do you need a local entity to accept payments? Model B — Foreign merchant + provider-enabled local acquiring Customer in Market B ↓ Existing merchant entity in Market A ↓ Global PSP ↓ Provider's eligible domestic acquiring route in Market B ↓ Permitted settlement structure This model is strategically important because it separates: access to local acquiring from: building a complete local corporate operation yourself. Provider infrastructure can sometimes give international merchants access to more localized processing arrangements. Current Checkout.com materials are one example of a provider offering domestic processing capabilities through a global acquiring platform. But this is exactly where merchants should avoid generalization. Availability may depend on: * merchant location; * target market; * acquiring entity; * merchant category; * card-network requirements; * business model; * payment method; * transaction flow; * provider policy; and * regulatory constraints. The correct feasibility question is: Can our existing legal entity access the acquiring route we want through this provider?

If yes, establishing a local merchant company solely for acquiring may provide little additional value. If no, a local entity may become part of the required architecture. That decision belongs in can you access local acquiring without incorporating? Model C — Local entity + local acquiring + local settlement Customer in Market B ↓ Merchant entity in Market B ↓ Domestic acquiring arrangement ↓ Local settlement currency/account ↓ Local merchant operating structure This is the deepest localization model. It can become relevant because of a combination of: * acquiring eligibility; * payment-method requirements; * licensing; * local commercial operations; * contracts; * banking; * tax; * settlement; * treasury design; or * other market-specific requirements. It can also be a deliberate commercial choice rather than a strict payment prerequisite. The important question is whether the benefits justify the structural cost. A local company can introduce additional work around: * incorporation and governance; * KYC/KYB; * bookkeeping; * accounts; * tax; * treasury; * intercompany flows; * local banking; * contracts; * compliance; * ongoing entity administration. Some of those questions belong to the next pillar section, Regulations, Licensing and Tax, rather than being answered here. The payment decision is narrower: Does this local structure unlock or materially improve the payment architecture we actually need? Local bank account does not mean local settlement—and vice versa

Payment terminology becomes especially confusing here. Consider four separate facts: Customer pays in BRL does not necessarily mean: Merchant's account balance is held in BRL which does not necessarily mean: Settlement occurs through Brazilian domestic banking rails which does not necessarily mean: The merchant must own a Brazilian company. Similarly: Merchant has a domestic bank account does not prove: Transactions are locally acquired. Adyen's current payout documentation illustrates this separation. It distinguishes settlement currencies from the location where funds are held and distinguishes local payouts from cross-border payouts; the available structure depends on acquiring geography, currency and bank-account location. Finance teams should therefore document the complete funds flow rather than asking simply: "Can we settle in this currency?" Map: Customer country → payment method → transaction currency → acquiring entity/route → merchant entity → balance/settlement currency → payout rail → receiving bank account → ultimate treasury destination Once that flow is visible, the local-bank requirement usually becomes much easier to diagnose. For the detailed banking question, see do you need a local bank account? The Market Entry Entity & Banking Decision Tree When entering a new market, work through the questions in this order. 1. What payment and acquiring model is needed? Start with customer access and processing requirements. Do not incorporate first and design payments afterward.

2. Can the existing foreign entity access that model? Ask the PSP/acquirer about the exact: * merchant country; * target market; * payment methods; * acquiring route; * merchant category; and * business model. A generic statement that the provider "supports Country X" is not enough. 3. Is local merchant registration or incorporation required? Determine why it would be required. Is the dependency: law/regulation? payment-method eligibility? acquirer requirement? PSP policy? commercial contract? tax/business presence? Those are different reasons and may produce different solutions. 4. Is local settlement required? Do not confuse: customer pays locally with: merchant must receive funds locally. Establish which settlement structures are actually supported. 5. Is a domestic bank account required? Ask whether the selected payout currency or local settlement arrangement requires an account in that jurisdiction. Some provider payout structures explicitly distinguish local and cross-border bank destinations. 6. Can the provider settle cross-border? If the answer is yes, determine: * supported currencies; * receiving-account requirements; * FX implications; * payout rails; * account-holder requirements; and * reconciliation consequences. Cross-border settlement may eliminate one structural requirement while creating another treasury tradeoff. 7. What regulatory, licensing and tax consequences arise? This is where payment architecture meets legal structure.

A structure that works technically is not automatically the right legal or tax structure. Move that analysis into the Regulations, Licensing and Tax workstream and obtain current market-specific advice. 8. Is the additional structure economically justified? Finally compare: Benefit of localization against: marginal complexity of localization. Possible benefits can include access to a desired acquiring route, payment method, settlement structure or commercial operating model. Costs can include: * entity administration; * banking; * compliance; * finance operations; * treasury; * accounting; * tax; * reconciliation; and * additional provider configuration. The merchant does not need the most localized architecture. It needs the minimum architecture that achieves the required payment outcome economically and compliantly. When local infrastructure earns its complexity A useful expansion principle is: Localize legal and banking infrastructure when the payment, commercial or regulatory benefit justifies it—not because "international expansion" sounds like it should require a local company. For one market, the optimal structure may be: foreign entity + global PSP + international settlement For another: foreign entity + provider-enabled domestic acquiring + cross-border settlement For another: local entity + domestic acquiring + domestic account and settlement And as the business grows, the answer can change.

A market that initially produces modest cross-border revenue may not justify its own entity and treasury operation. If that market later becomes one of the merchant's largest businesses, the economics of deeper localization may change. That makes entity design a payment-architecture decision with legal consequences, not a checkbox at the beginning of international expansion. Before incorporating, opening another bank account, or building another treasury process, work backward from the payment flow: Which customers must we serve? → Which methods and acquiring routes do we need? → Which entity can access them? → Where can settlement occur? → Which bank infrastructure is actually necessary? → What legal and tax consequences follow? → Does the value justify the additional operating structure? That sequence replaces the vague question— "Do we need a local entity?" —with the one that matters: "What is the minimum legal and banking footprint required to support the payment model we have chosen for this market?" Disclaimer: This content provides general information and does not constitute legal, regulatory, tax, accounting, or financial advice. Requirements vary by market, merchant structure, business model, payment method, payment provider, acquirer, and applicable regulation. Merchants should verify current requirements with qualified advisers, relevant authorities, and their payment providers or acquirers. 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

C. ORIGINAL SECTION ASSET — NOT PILLAR COPY Market Entry Entity & Banking Decision Tree For the supporting graphic, I recommend a real branching decision tree rather than a linear checklist: START: Target payment experience ↓ 1. What payment methods / acquiring model do we need? ↓ 2. Can our existing foreign entity access it? YES → continue with existing entity NO → identify exact restriction ↓ 3. What creates the restriction? * Legal/regulatory * Acquirer * Payment method * PSP policy * Commercial/operational ↓ 4. Is local merchant registration/entity required? NO → retain foreign entity YES → evaluate local structure ↓ 5. Where must/can settlement occur? * Existing foreign account * Cross-border account * Domestic/local settlement ↓ 6. Is a domestic bank account required for that payout model? NO → cross-border settlement architecture YES → establish/qualify local banking arrangement ↓ 7. What tax/licensing/legal consequences follow? ↓ 8. Is localization economically justified? → Model A: Foreign merchant + global PSP → Model B: Foreign merchant + provider-enabled local acquiring → Model C: Local entity + local acquiring + local settlement A footer should read: Local entity ≠ local acquiring ≠ local bank account ≠ local settlement

D. INTERNAL-LINK PLAN — NOT PILLAR COPY Priority Recommended anchor Destination Type Why it belongs here 1 do you need a local entity to accept payments? Do You Need a Local Entity to Accept Payments? Specialist cluster Owns the deeper entity-requirement search intent 2 do you need a local bank account? Do You Need a Local Bank Account? Specialist cluster Deepens the settlement-account question without bloating the pillar 3 accept payments without local incorporation How to Accept Payments Without Local Incorporation Specialist cluster Natural destination from Model A 4 when a merchant needs a local entity When Does a Merchant Need a Local Entity? Specialist/local-acquiring cross-link Natural destination from Model C 5 access local acquiring without incorporating Can You Access Local Acquiring Without Incorporating? Specialist/local-acquiring cross-link Owns the key Model B question 6 local acquiring versus cross-border acquiring Local Acquiring vs Cross-Border Acquiring Local Acquiring cluster Useful where the section begins from processing architecture 7 local settlement versus international settlement Local Settlement vs International Settlement Entity/Settlement cluster Supports the bank-versus-settlement distinction I would keep this section to five primary inline links, using links 6–7 only where the final pillar's neighboring sections do not already link them heavily.

No country guide is essential here unless a later version introduces a concrete country-specific entity/bank example. That depth belongs in specialist articles rather than this synthesis section. Reciprocal links back to the pillar The five dedicated entity/banking articles should link back naturally using variations such as: * international payment expansion * payment requirements when entering new markets * international market-entry payment infrastructure * expanding payments internationally

E. SEO SUPPORT — NOT PILLAR COPY Suggested H2: Local Entities and Bank Accounts Suggested H3s 1. Local entity and local bank account are different decisions 2. Work backward from acquiring and settlement 3. Three common market-entry structures 4. Local bank account does not mean local settlement—and vice versa 5. The Market Entry Entity & Banking Decision Tree 6. When local infrastructure earns its complexity Secondary semantic terms Use naturally rather than trying to rank this pillar section for all of them: * foreign merchant * domestic merchant * local incorporation * payment legal entity * domestic bank account * settlement account * cross-border settlement * local settlement * domestic acquiring * local acquiring * merchant acquiring * merchant ID * payout currency * settlement currency * acquiring entity * international payment processing * market-entry payment infrastructure Featured-snippet opportunity A strong snippet candidate is the four-way distinction: A local entity, local bank account, local acquiring arrangement and local settlement structure are different parts of an international payment setup. Whether a merchant needs each one depends on the target market, payment method, acquiring route, settlement design, provider and applicable legal requirements. Supporting visual Market Entry Entity & Banking Decision Tree Use the three-model outputs as visually distinct endpoints rather than illustrating one "correct" structure. Recommended alt text

“International payment market-entry decision tree comparing a foreign merchant using a global PSP, a foreign merchant accessing local acquiring through a provider, and a local entity using domestic acquiring and local settlement.”

F. EVIDENCE AND VERIFICATION PLAN — NOT PILLAR COPY Strong current primary-source support Adyen — supported settlement currencies / payout architecture. Particularly useful because its current documentation explicitly distinguishes acquiring region, settlement currency, bank-account location, local payout and cross-border payout. This is strong evidence for the article's insistence that settlement and bank location are separate architectural variables. Checkout.com — global acquiring. Its current acquiring material documents domestic-processing capabilities delivered through a global platform. This supports Model B conceptually without implying that every merchant can use every domestic acquiring route. Checkout.com — settlement bank-account changes. Useful evidence that the settlement-account relationship itself is verified and that a bank-account holder belonging to another entity can require explanation. Stripe — cross-border bank transfers. Useful illustration that customer access to local bank rails need not be synonymous with the merchant maintaining its own account setup in the customer's country. Keep this strictly within the documented Stripe use case.

Claims requiring market-by-market verification Before inserting any concrete country example, verify: * whether foreign merchants can access the intended payment method; * whether local acquiring is available to a foreign entity; * whether a domestic merchant ID is required; * whether local registration/incorporation is required; * whether a local settlement account is required; * which payout currencies are available; * whether FX or capital controls affect repatriation; * any merchant licensing requirement; * tax consequences of establishing local presence. These should be checked against the relevant provider/acquirer plus official regulatory, tax and government sources. Law versus provider policy Editorial review should label each requirement as one of: law/regulation licensing requirement scheme/payment-method rule acquirer requirement PSP policy commercial choice A provider saying "we require a local entity for this configuration" must not be rewritten as: "Country X legally requires foreign merchants to incorporate."

* which local acquiring connections can be accessed without a merchant local entity; * situations requiring or favoring a local entity; * whether specific local payment methods impose merchant-country/entity conditions; * domestic versus cross-border settlement; * local-bank-account requirements by currency/market; * multi-entity settlement configuration; * current payout currencies; * current local-acquiring markets;

G. HUMAN REVIEW RECOMMENDATION — NOT PILLAR COPY Primary subject-matter reviewer: International payments strategist or acquiring specialist who can validate Models A/B/C and the local-versus-cross-border acquiring distinction. Treasury/finance reviewer: Treasury or international finance specialist to review local bank account, settlement account, payout currency and cross-border settlement terminology. Legal/compliance reviewer: Cross-border payments counsel or regional compliance specialist to make sure commercial/provider requirements are not presented as local law. Tax reviewer: International tax specialist only if the published section expands beyond the current high-level warning about local-entity tax consequences. Payment operations reviewer: Head of Payments or payment operations lead with experience coordinating PSP, entity and bank-account structures across multiple markets.

The intellectual center of this section should remain: Design the payment flow first. Add legal and banking infrastructure only when that flow, applicable requirements, or its economics justify it.