Detecting Aggregator-Within-Aggregator: A Payment Compliance Framework
Detecting Aggregator-Within-Aggregator: A Payment Compliance Framework
Nested payment relationships can hide high-risk sub-merchants and trigger regulatory fines. We provide a practical compliance framework to uncover "aggregators-within-aggregators," giving you full visibility into your merchant ecosystem. Learn how to strengthen your KYB and transaction monitoring to stay ahead of card scheme audits.
How payment and risk teams can identify hidden sub-merchant infrastructure, map ecosystem complexity, and distinguish direct merchants from disguised aggregators before portfolio risk escalates.
The riskiest sub-merchant is the one nobody admits exists.
Some platforms are just aggregators in disguise.
When a merchant approaches you for payment processing claiming to sell products or services directly to consumers, the complexity isn't in evaluating their product quality or market position. It's in determining whether they're operating as the direct merchant they claim to be or whether they've built infrastructure that enables dozens or hundreds of other sellers to transact through their payment rails. Unlike most merchant categories where you verify business legitimacy and fraud controls, potential aggregators require you to become a functional analyst, mapping technical infrastructure and payment flows to identify whether the business crosses the line from direct sales to payment facilitation.
This guide walks you through the complete assessment framework we use at Ballerine to evaluate potential aggregator-within-aggregator scenarios and distinguish legitimate direct merchants from disguised payment facilitators.
Understanding the Aggregator-Within-Aggregator Challenge
The Regulatory Challenge
The payment facilitation industry exists in a defined regulatory space with clear card network rules and compliance obligations. Payment facilitators (PayFacs) and Independent Sales Organizations (ISOs) that onboard sub-merchants must register with card networks, implement sub-merchant underwriting programs, and maintain ongoing monitoring. These requirements are well-established.
The challenge for compliance teams emerges when merchants deliberately obscure their true business model, using direct merchant language and single-entity presentations while operating functionally as aggregators. This creates three critical problems:
Regulatory Exposure: When you underwrite a merchant as a direct seller but they're actually facilitating payments for unvetted sub-merchants, you inherit liability for those hidden third parties. Card network rules require visibility into all parties in the payment chain.
Risk Concentration: A single merchant relationship can expose your portfolio to hundreds of unvetted businesses. One compliance failure, fraud pattern, or regulatory violation by any sub-merchant creates liability for your organization.
Portfolio Integrity: Hidden aggregators undermine portfolio risk modeling. Your risk assessments assume you're evaluating discrete businesses, not networks of unknown sellers operating under false pretenses.
How Platforms Hide Aggregator Operations
Following the expansion of e-commerce infrastructure and marketplace platforms, the techniques for disguising aggregator operations have become sophisticated. Operators use various structures to obscure sub-merchant activity:
Clean Presentation Layer: The merchant onboarding presents spotless business documentation showing a single legal entity with clear ownership, straightforward operations, and direct sales claims. All initial documentation reviews pass standard underwriting checks.
Technical Obfuscation: Payment flows split to multiple beneficiaries through backend configurations invisible during standard document review. Seller tools exist behind authentication walls. Sub-merchant onboarding happens on separate domains or subdomains not disclosed during underwriting.
Legal Structure Gaming: Terms of service carefully avoid explicit aggregator language while enabling all the functionality. They may call sub-merchants "partners," "affiliates," or "collaborators" rather than "sellers" or "vendors."
The Stakes
The financial and regulatory consequences of missing these patterns include:
Card Network Fines: Visa and Mastercard impose fines for unregistered payment facilitation activity. These can reach millions of dollars depending on transaction volume.
Banking Relationship Termination: When acquiring banks discover unregistered aggregation, they terminate the merchant relationship, often immediately.
Regulatory Action: FinCEN and state regulators can pursue money transmission violations when platforms facilitate payments without proper licensing.
Liability for Sub-Merchant Misconduct: Chargebacks, fraud losses, and regulatory violations by unknown sub-merchants become your exposure.
Key takeaway: Even if a merchant claims to be "just a direct seller" or presents as a single business entity, functional analysis determines regulatory classification. Your underwriting must identify facilitation patterns to maintain payment compliance and avoid inheriting unmanaged risk.
The Regulatory Context
Federal and Card Network Framework
Before examining specific merchant characteristics, understand the legal frameworks that apply when platforms facilitate payments for others:
Card Network Rules
Visa and Mastercard maintain Payment Facilitator Registration Programs. Any entity that enables sub-merchants to accept card payments must:
Register with the card networks as a payment facilitator
Implement sub-merchant onboarding and underwriting programs
Maintain ongoing monitoring of sub-merchant activity
Report sub-merchant data to the networks
Accept liability for sub-merchant violations
Operating as a de facto payment facilitator without registration violates card network rules and triggers fines, enforcement actions, and potential termination of payment processing relationships.
FinCEN Requirements
The Financial Crimes Enforcement Network Customer Due Diligence Requirements mandate that money services businesses identify beneficial owners of all parties in payment flows. When platforms facilitate payments for others, those third parties must be identified and verified.
Platforms that split payments to multiple beneficiaries may trigger money transmitter licensing requirements at the state level. Requirements vary by state but generally apply when the platform holds, transfers, or disburses funds on behalf of others.
PCI DSS Obligations
PCI DSS requires payment facilitators to maintain separate validation for sub-merchants. When a merchant presents as direct but operates as an aggregator, they often lack proper PCI compliance programs for their hidden sub-merchants, creating data security exposure.
State Money Transmitter Laws
Many states require money transmitter licenses for payment facilitation activity. Platforms that receive customer payments and disburse funds to sellers are transmitting money. Operating without required state licenses creates regulatory violations and potential criminal liability.
Industry-Specific Considerations
Certain industries have higher aggregator risk:
Marketplace and Multi-Vendor Platforms: SaaS platforms serving e-commerce sellers, event ticketing platforms, rental marketplaces, and service provider networks frequently enable payment facilitation as a core feature.
Franchise and Network Models: Franchise systems, MLM organizations, and reseller networks often centralize payment processing for distributed seller networks.
Gig Economy Platforms: Platforms connecting service providers with customers often process payments on behalf of independent contractors who function as sub-merchants.
For fintech and marketplace companies, these patterns are especially common.
The Complete Assessment Framework
1. Payout Flow Analysis
Why it matters: Payment flows reveal what business documentation conceals. When money systematically splits to multiple bank accounts, routes through different entities, or follows seller-specific logic, you're looking at sub-merchant activity regardless of what the platform claims.
This is the single most reliable indicator of hidden aggregation. Business documents lie. Payment flows don't.
High-Risk Payout Patterns
Systematic Split Payments
Payments from customers route to a primary account, then automatically split to multiple beneficiary accounts
Different bank accounts receive payouts for different transaction subsets
Payout logic based on product ID, seller ID, or transaction metadata
Why this is critical risk: Automated payment splitting to third parties is the defining characteristic of payment facilitation. This pattern has no legitimate explanation in direct merchant operations.
Multiple Beneficiary Accounts
Transaction settlements flow to more than one legal entity
Different days of the week or different product categories settle to different accounts
Account beneficiaries include individuals or businesses not disclosed during underwriting
Why this is critical risk: Direct merchants settle to a single beneficiary account. Multiple beneficiaries indicate multiple economic interests in the transactions, meaning sub-merchant activity.
Revenue Share Settlement Logic
Payout amounts suggest commission or revenue share calculations (e.g., 70% to one account, 30% to another)
Settlement amounts don't match gross transaction values (indicating platform is taking a cut)
Payouts occur on different schedules for different recipients
Why this is high risk: Revenue sharing is how aggregators compensate sub-merchants. This settlement structure indicates facilitation.
Third-Party Payment Processor Relationships
The merchant uses payment processors known for serving marketplaces or multi-vendor platforms (Stripe Connect, Adyen for Platforms, PayPal Commerce Platform)
Processor integration includes marketplace or split payment features
API documentation references "connected accounts" or "sub-merchant accounts"
Why this is high risk: Merchants don't use sophisticated marketplace payment infrastructure unless they're operating marketplaces.
Acceptable Payout Patterns
Single Beneficiary Settlement
All transaction settlements flow to one bank account
Account beneficiary matches the legal entity underwritten
Consistent settlement schedule and logic
No Split Payment Logic
Payment processor configurations show standard merchant account setup
No references to sub-accounts, connected accounts, or split settlements
API integrations are standard merchant integrations, not marketplace tools
Transparent Payment Processor Relationships
Uses payment processors appropriate for direct merchant operations
Can provide complete documentation of payment processor setup
No hidden or undisclosed processor relationships
What to Request from Merchant
Documentation category
Required materials
Bank Statements
Last 6 months of statements for all business accounts
Settlement reports from all payment processors
Explanation of any accounts showing disbursements to third parties
Payment Processor Configuration
Complete processor account setup documentation
API integration specifications
List of all processor accounts (current and historical)
Settlement schedule and logic documentation
Payout Logic Documentation
Technical documentation of payment routing
If any payment splits occur, complete explanation of why
List of all bank accounts that receive any portion of customer payments
Reconciliation Reports
Sample transaction-to-settlement reconciliation
Documentation explaining any differences between transaction amounts and settlement amounts
Explanation of any fees or splits
Investigation Steps
Bank Statement Analysis
Analyze 6 months of bank statements looking for:
Consistent patterns of outgoing transfers to third parties
Transfers labeled as "payout," "seller payment," "vendor payment," "commission," etc.
Transfers that correlate with incoming payment processor settlements
Multiple accounts receiving portions of the same deposit batch
Payment Processor Deep Dive
Request complete access to payment processor configurations:
Review all account settings
Check for enabled marketplace or split payment features
Review API integration code if accessible
Verify processor account type (standard merchant vs. platform/marketplace account)
Transaction Flow Mapping
For a sample transaction, map the complete flow:
Customer payment: $100
Payment processor receives: $100
Processor fee: $3
Settlement to merchant: $97
Does merchant keep $97 or split it? This is the critical question.
If the merchant keeps the full settlement (minus their own business expenses), they're a direct merchant.
If the merchant systematically splits settlement to third parties, they're facilitating payments.
Comparative Analysis
Compare their payment flows to known direct merchants in the same industry:
Do other direct merchants in this space use these payment processors?
Do other direct merchants have similar settlement patterns?
Are there industry norms this merchant deviates from?
Merchant Assessment Checklist
Settlement Characteristics
All settlements flow to single beneficiary account matching underwritten entity
No systematic splits to third-party accounts
Settlement amounts match transaction values (minus standard processor fees)
No revenue-share or commission logic in settlement patterns
Payment Processor Configuration
Standard merchant account type (not marketplace or platform account)
No split payment or connected account features enabled
Processor relationship matches direct merchant profile
Complete transparency in processor setup
Documentation Completeness
Can provide all bank statements for all business accounts
Can explain all outgoing transfers from settlement accounts
Transaction-to-settlement reconciliation is straightforward
No undisclosed payment routing or third-party disbursements
Red flag threshold:
ANY systematic split payments to third parties = CRITICAL RISK (Automatic decline without acceptable explanation)
Multiple beneficiary accounts = CRITICAL RISK
Revenue share settlement logic = CRITICAL RISK
Marketplace payment processor features enabled = HIGH RISK
Inability to explain settlement patterns = HIGH RISK
For merchant acquiring platforms, automated payout flow analysis during underwriting prevents onboarding hidden aggregators.
2. Onboarding Infrastructure Investigation
Why it matters: The systems a platform builds reveal their true business model. Direct merchants need customer onboarding. Aggregators need seller onboarding. The presence of seller onboarding infrastructure, regardless of what they call it, indicates sub-merchant operations.
High-Risk Onboarding Patterns
Self-Service Seller Registration
Public-facing registration forms where third parties can sign up to sell
Automated account creation without manual review
"Become a Seller," "Start Selling," "Partner with Us," or "Join Our Marketplace" flows
Registration forms collect business information from multiple entities
Why this is critical risk: Self-service seller onboarding is the hallmark of marketplace platforms. Direct merchants don't need this infrastructure.
Multi-Entity Information Collection
During registration, the platform collects:
Business registration documents from multiple companies
Tax identification numbers (EIN/SSN) from different parties
Bank account information from various entities
Individual identity verification for multiple people
Why this is critical risk: Direct merchants collect this information once, about themselves. Collecting it repeatedly from different parties indicates sub-merchant onboarding.
Tiered Account Structures
Different user roles: "Admin," "Seller," "Vendor," "Partner"
Hierarchical permissions showing some users can manage others
"Store owner" or "shop manager" roles separate from platform admin
Documentation referring to "your sellers" or "your vendors"
Why this is high risk: Tiered account structures with seller-specific roles serve no purpose in direct merchant operations. They exist to manage sub-merchant networks.
Identity Verification Infrastructure
Integration with KYC/KYB providers (Jumio, Onfido, Trulioo) for ongoing verification
Repeated identity verification workflows (not just at initial company sign-up)
Documentation indicating verification occurs for "each seller" or "each vendor"
Why this is high risk: Robust identity verification infrastructure for ongoing account creation indicates systematic onboarding of third parties.
Business Document Collection Systems
Automated systems for collecting and storing business licenses, certificates, permits
Document requirements listed for "each seller" or "each vendor"
Approval workflows showing review of business documents before account activation
Why this is high risk: Direct merchants submit their own documents once. Systems built to collect documents from many parties indicate sub-merchant operations.
Acceptable Onboarding Patterns
Single-Entity Onboarding
Company completes one onboarding process at initial setup
No ongoing onboarding for additional parties
Any additional users are employees of the underwritten entity
Tiered account structures with seller-specific roles = HIGH RISK
Collects business information from multiple entities = CRITICAL RISK
KYC integration for ongoing third-party verification = HIGH RISK
Cannot demonstrate registration flow transparency = HIGH RISK
3. Terms of Service and Legal Language
Why it matters: Terms of service drafters carefully avoid explicitly stating "we're an aggregator" or "we facilitate payments for sub-merchants." But legal documents must still describe what the platform actually does. Reading for functional capabilities rather than explicit labels reveals aggregator infrastructure.
The presence of certain legal provisions has no explanation except multi-party payment operations.
High-Risk Legal Language
Seller, Vendor, or Partner Provisions
Terms of Service includes sections titled:
"For Sellers"
"Vendor Agreement"
"Partner Terms"
"Marketplace Rules"
"Sub-Merchant Terms"
Or references such as:
"our sellers"
"merchants on our platform"
"third-party sellers"
"independent vendors"
Why this is critical risk: Direct merchants don't need seller agreements. These provisions exist to govern sub-merchant relationships.
Commission and Revenue Share Language
"We charge sellers X% per transaction"
"Commission structure"
"Revenue split"
"Platform fee charged to vendors"
"Service fee on sales"
"We retain X% and pay Y% to the seller"
Why this is critical risk: Commission structures are how aggregators make money. Direct merchants sell products/services and keep revenue. Platforms that "charge sellers" are facilitating their transactions.
Third-Party Liability Disclaimers
"We are not responsible for seller conduct"
"Products are sold by independent vendors"
"We do not guarantee third-party seller performance"
"Disputes should be resolved directly with the seller"
"Sellers are responsible for their own tax obligations"
Why this is high risk: These disclaimers exist to limit platform liability for sub-merchant actions. Direct merchants can't disclaim responsibility for their own conduct.
Seller Performance Policies
Seller performance standards (shipping time requirements, response rates)
Seller rating and review systems
Account suspension or termination for seller policy violations
"Seller Code of Conduct"
Why this is high risk: Performance management systems govern third-party behavior. Direct merchants don't need to enforce policies against themselves.
Indemnification Protecting Platform from Seller Actions
"Sellers indemnify the platform for claims arising from their products"
"Sellers are solely responsible for compliance with applicable laws"
"Platform is not liable for seller intellectual property violations"
Why this is high risk: Indemnification clauses shift liability from platform to sellers, which only makes sense when sellers are separate entities.
Payment Processing Language
"We process payments on behalf of sellers"
"We facilitate transactions between buyers and sellers"
"Payment will be split between the platform and seller"
"We hold funds in escrow and release to sellers upon completion"
Why this is critical risk: This is explicit payment facilitation language.
Multi-Party Transaction Structure
Terms describe transactions as involving platform, buyer, and seller (three parties)
Different warranties apply to platform services vs. seller products
Separate refund policies for platform fees vs. seller proceeds
Why this is high risk: Three-party transaction structure indicates marketplace operations, not direct sales.
Acceptable Legal Language
Single-Entity Transaction Structure
Terms describe transactions as between the company and customer (two parties)
Company is responsible for all products/services sold
No references to third-party sellers or vendors
Direct Seller Warranties
Company warrants product quality, service delivery, compliance
No disclaimers of responsibility for third-party conduct
Clear accountability for all customer-facing operations
Standard E-Commerce Language
Privacy policy covers company data collection only
Refund policy applies to all products uniformly
Customer support provided by company
No Revenue Split References
No commission structures
No language about "fees charged to sellers"
All revenue discussion relates to customer pricing
What to Request from Merchant
Documentation category
Required materials
Terms of Service
Current and all historical versions
Any separate seller, vendor, or partner agreements
Any marketplace rules or policies
Privacy Policy
Current version
Does it reference multiple parties in data collection?
Refund/Return Policy
Who processes refunds?
Are refunds handled uniformly or per-seller?
Business Model Documentation
How does the company describe its operations in legal documents?
Any contracts with “sellers” or “vendors”
Intellectual Property Policies
Who owns content uploaded to platform?
Any provisions about seller-uploaded content?
Investigation Steps
Keyword Search
Search Terms of Service and related documents for:
"seller" / "sellers"
"vendor" / "vendors"
"partner" / "partners"
"merchant" / "merchants"
"commission"
"revenue share" / "revenue split"
"platform fee"
"third party" / "third-party"
"marketplace"
"facilitate"
"on behalf of"
Document every instance and surrounding context.
Section Analysis
Read carefully for:
Who are the parties to transactions?
Who bears liability for what aspects?
How is money described as flowing?
Are there provisions governing third-party behavior?
Historical Comparison
If the company has been operating for several years:
Request historical versions of Terms of Service
Look for changes over time
Did seller provisions get added later?
Were marketplace references removed before applying for processing?
This reveals attempts to hide aggregator operations during underwriting.
Legal Entity Cross-Reference:
Does the legal entity in Terms of Service match the entity applying for processing?
Are there references to multiple legal entities?
Do seller agreements reference different entities?
Competitor Comparison
Compare Terms of Service to:
Known direct merchants in the industry
Known marketplace platforms in the industry
Where does this merchant's language align?
Merchant Assessment Checklist
Transaction Structure
Terms describe two-party transactions (company and customer)
No references to sellers, vendors, or third-party merchants
Company assumes full responsibility for all products/services
No liability disclaimers related to third-party conduct
Revenue Model
No commission, revenue share, or fee-to-sellers language
All revenue discussion relates to customer pricing
No payment facilitation language
No descriptions of splitting or holding funds for others
Legal Accountability
Company provides all warranties and guarantees
No indemnification from sellers to platform
Customer service and support provided by company
No seller performance policies
Documentation Consistency
Terms of Service consistent with business model presented during underwriting
No hidden seller or vendor agreements
Historical versions show consistent positioning
Legal entity matches application
Red flag threshold:
References to "our sellers" or similar language = CRITICAL RISK
Commission or revenue share provisions = CRITICAL RISK
Seller agreements or marketplace rules exist = CRITICAL RISK
Three-party transaction structure = HIGH RISK
Indemnification from sellers to platform = HIGH RISK
Payment facilitation language = CRITICAL RISK
4. Seller Tools and Platform Capabilities
Why it matters: The functionality built into a platform reveals what operations it enables. Platforms don't accidentally build sophisticated seller dashboards, inventory management systems, or order routing tools. These capabilities exist for specific purposes.
If those purposes include enabling third parties to manage their own sales operations, you're looking at aggregator infrastructure.
Performance metrics for individual sellers (conversion rates, average order value)
Sales reports broken down by seller
Revenue tracking per seller
Tools for sellers to analyze their own performance
Why this is critical risk: Sellers need dashboards. Direct merchants have one dashboard for their entire business. Multiple seller dashboards indicate sub-merchant operations.
Inventory Management for Multiple Parties
Individual sellers can add/edit their own product listings
Each seller manages their own inventory levels
Products are associated with specific seller accounts
Bulk upload tools for seller product catalogs
Why this is critical risk: If different parties control different portions of inventory, they're different merchants.
Order Fulfillment Routing
Orders route to different fulfillment locations based on seller
Sellers receive order notifications independently
Shipping and tracking managed per-seller
Different sellers can have different shipping policies
Why this is high risk: Order routing to different entities for fulfillment indicates those entities are the actual merchants.
Seller Communication Tools
Messaging systems allowing buyer-seller communication
Seller support ticket systems separate from platform support
Tools for sellers to respond to customer inquiries about their products
Review and rating systems for individual sellers
Why this is high risk: When customers need to contact specific sellers rather than the platform, those sellers are the actual merchants.
Payout and Financial Management Tools
Sellers can view their pending payouts
Financial dashboards showing seller earnings
Tools to manage bank account information for receiving payments
Tax document generation per seller (1099s, etc.)
Why this is critical risk: Individual payout tracking and tax document generation proves multi-party financial operations.
Seller Onboarding and Account Management
Sellers can update their business information
Tools to manage business verification documents
Seller identity re-verification workflows
Account settings specific to seller operations
Why this is high risk: Ongoing seller account management tools serve no purpose except managing sub-merchant relationships.
Storefront Customization
Sellers can customize their "shop" or "store" within the platform
Individual branding per seller
Different visual themes or layouts per seller
Custom domain or subdomain options for sellers
Why this is high risk: Storefront customization enables sellers to present branded experiences, indicating they're independent merchants using shared infrastructure.
Acceptable Platform Capabilities
Single Admin Dashboard
One dashboard showing complete business operations
Managed by employees of the underwritten entity
All functionality relates to company's direct operations
Unified Inventory Management
All products managed by company
No seller-specific inventory controls
Employees manage all listings
Centralized Order Processing
All orders processed by company
Single fulfillment workflow
Company handles all customer communication
Customer-Facing Tools Only
Customer accounts for making purchases
Order tracking for customer convenience
Customer support managed by company
Internal User Management
Additional users are employees
Permissions relate to job functions (customer service, marketing, logistics)
No seller or vendor management capabilities
What to Request from Merchant
Documentation category
Required materials
Platform Documentation
Complete feature list
User guides for all functionality
Screenshots of all user interface areas
API documentation
Demo Access
Full admin panel access
Access to all user types if multiple exist
Ability to navigate all features
Technical Architecture
System architecture diagrams
Database schemas
Third-party integrations list
Seller Tools Documentation
If any seller-facing tools exist, complete documentation
Explanation of purpose for each feature
Who uses these tools?
Testing Protocol
Comprehensive Platform Review
Request demo access and systematically review:
Main Dashboard
What information is displayed?
Are there sections for different sellers?
Can you filter or segment by any seller-related dimension?
Product/Service Management
Who can add new listings?
Are listings associated with specific sellers?
Can different users manage different subsets of products?
Order Management
How are orders displayed?
Do orders route to different parties?
Who fulfills orders?
Financial/Reporting Section
Are there financial breakdowns by seller?
Can individual sellers view their own earnings?
Are there payout management tools?
User Management
What user types exist?
Can admin create seller accounts?
What permissions can sellers have?
Communication Tools
How do customers contact the business?
Is there seller-specific messaging?
Who responds to customer inquiries?
API Documentation Review
If API documentation is available:
Look for endpoints related to:
/sellers/
/vendors/
/merchants/
/payouts/
/sub-accounts/
Review data models:
Do data structures include seller_id, vendor_id, merchant_id fields?
Are transactions associated with specific sellers?
Integration capabilities:
Can third parties integrate to manage their operations?
Technical Pattern Recognition
Look for architectural patterns common in marketplace platforms:
Multi-tenancy (different sellers operating in isolated environments)
Role-based access control with seller-specific permissions
Seller-specific data isolation
Sub-account or connected account structures
Competitive Analysis
Compare platform capabilities to:
Known marketplace platforms in the industry (Etsy, Amazon Marketplace, Shopify Plus with multi-vendor capabilities)
Known direct merchant platforms (standard e-commerce sites)
Where does this merchant's technical sophistication align?
Merchant Assessment Checklist
Dashboard and Analytics
Single dashboard for entire business operations
No seller-specific performance metrics
All analytics relate to company's direct sales
No tools for third parties to view their own performance
Inventory and Product Management
All products managed by company employees
No seller-specific inventory controls
Unified product catalog
No tools for third parties to manage their own listings
Order Processing
All orders fulfilled by company
Unified order management workflow
No routing to different entities based on product or seller
Company handles all customer communication
Financial Tools
No seller-specific financial dashboards
No individual payout tracking for third parties
No tax document generation for multiple parties
All financial management relates to company operations
User Management
Users are employees of the underwritten entity
No seller or vendor account types
Permissions relate to internal job functions
No third-party account management
Red flag threshold:
Seller dashboards exist = CRITICAL RISK
Individual sellers can manage inventory = CRITICAL RISK
Order routing to different entities = HIGH RISK
Seller financial management tools = CRITICAL RISK
Messaging between buyers and specific sellers = HIGH RISK
Storefront customization per seller = HIGH RISK
For banking compliance teams, thorough technical review during underwriting prevents post-onboarding discoveries of hidden aggregator infrastructure.
5. Ecosystem Mapping and Domain Architecture
Why it matters: Single-domain evaluation misses the complexity of distributed operations. Hidden aggregators often operate seller-facing infrastructure on separate domains, subdomains, or white-labeled properties not disclosed during underwriting.
URL structure like: seller-name.platform.com or platform.com/seller-name
Each subdomain or path shows different seller branding
Different product catalogs per subdomain
Different contact information per subdomain
Why this is critical risk: Individual seller storefronts indicate marketplace operations. Each subdomain represents a different merchant using shared payment infrastructure.
Separate Seller Portal Domain
Different domain for seller login and management (e.g., sellers.platform.com, partner-portal.platform.com)
Seller onboarding occurs on separate domain
Seller resources and documentation on different property
Why this is high risk: Segregating seller-facing infrastructure suggests intentional obscuring of aggregator operations. The separation serves to hide sub-merchant activity from primary brand presentation.
White-Label Seller Storefronts
Sellers can use custom domains pointing to platform infrastructure
DNS records show multiple domains resolving to same platform servers
Why this is critical risk: White-labeling enables sellers to present as independent businesses while using platform payment facilitation, obscuring the aggregation relationship.
Multiple Properties Under Same Control
Different domains owned by same entity or related entities
Shared infrastructure (same hosting, same CMS, same payment processors)
Cross-linking or shared resources between properties
Why this is high risk: Multiple related properties can indicate distributed seller operations or attempts to segment high-risk activities across different merchant accounts.
Ecosystem Mapping Requirements
According to regulatory best practices and Mastercard standards, merchant risk assessments must include an "Ecosystem" section mapping:
All domains and subdomains operated by the same entity or people
Related websites sharing ownership, management, or infrastructure
White-label storefronts powered by the platform
Any properties where products from the merchant's catalog appear
This mapping reveals the true scope of operations and identifies hidden sub-merchant activity distributed across multiple properties.
What to Request from Merchant
Documentation category
Required materials
Complete Domain List
All domains owned or operated by the company
All subdomains in use
Any white-label or custom domain capabilities provided to third parties
Infrastructure Documentation
Hosting providers for all properties
Shared infrastructure across domains
DNS configuration documentation
Related Entity Disclosures
Any related companies, subsidiaries, or affiliated entities
Multiple undisclosed domains discovered = HIGH RISK
Infrastructure indicates marketplace platform = HIGH RISK
Attempts to hide properties or related entities = CRITICAL RISK
6. Revenue Model Deconstruction
Why it matters: How a merchant makes money reveals their true business model more reliably than any self-description. Platform claims about being a "direct seller" or "service provider" become meaningless when revenue comes from commissions on third-party sales.
Revenue model analysis requires financial documentation, not just business descriptions.
High-Risk Revenue Models
Commission-Based Revenue
Primary revenue from "fees charged to sellers"
"Platform fee" or "service fee" as percentage of third-party sales
Revenue scales with number of sellers and their transaction volume
Why this is critical risk: Commission-based revenue models are how aggregators operate. The platform facilitates transactions and takes a cut. This is payment facilitation.
Transaction Volume Revenue Share
Revenue agreements with payment processors based on facilitated transaction volume
"We earn X% of payment processing volume"
Revenue increases as sellers process more transactions
Platform has financial incentive for sellers to transact more
Why this is critical risk: Revenue that scales with facilitated transaction volume indicates the platform's business is payment facilitation, not direct sales.
Seller Subscription with Small Share of Revenue
Sellers pay monthly/annual subscription to platform
BUT: Platform also takes commission on transactions
If transaction volume is significantly higher than revenue, where does the difference go? This pattern suggests the merchant is facilitating transactions and keeping only a commission.
Acceptable explanation: "We're a high-volume, low-margin business. Transaction volume is $1M, our cost of goods sold is $800K, gross margin is $200K."
Unacceptable explanation: "Transaction volume is $1M, we keep $200K as platform fees, $800K goes to sellers."
The second scenario is payment facilitation.
Unit Economics Analysis
Request documentation of unit economics:
What is sold?
What does the customer pay?
What does the company keep?
What costs exist in delivering the product/service?
For a direct merchant:
Customer pays: $100
Company keeps: $100 (full sale amount)
Company pays for: product cost $60, shipping $10, operations $20
If growth plans focus on seller acquisition and seller transaction volume, you're looking at an aggregator.
Competitive Benchmarking
Research financial models of similar companies:
What are revenue multiples in this industry?
What are typical margins?
How do known direct merchants vs. known marketplaces monetize?
Merchant Assessment Checklist
Revenue Composition
Over 80% of revenue from direct sales of company's products/services
No commission or platform fees charged to sellers
No transaction-based revenue from facilitating third-party sales
Any affiliate revenue is clearly disclosed and <20% of total
Financial Alignment
Transaction volume matches reported revenue (accounting for standard margins)
Financial statements show direct sales business model
Unit economics demonstrate direct merchant operations
No revenue share agreements with sellers
Growth Strategy
Growth plans focus on direct customer acquisition
Revenue scales with direct sales, not seller network growth
Company success not dependent on seller transaction volume
No seller acquisition targets or seller volume goals
Documentation Transparency
Can provide complete revenue breakdown
Financial statements clearly show revenue sources
No hidden or unexplained revenue streams
Projections consistent with direct merchant model
Red flag threshold:
Commission-based revenue >20% of total = HIGH RISK
Commission-based revenue >50% of total = CRITICAL RISK
Transaction volume significantly exceeds reported revenue = HIGH RISK
Revenue scales with seller network, not direct sales = HIGH RISK
Freemium model for sellers with transaction-based monetization = CRITICAL RISK
Cannot provide clear revenue source breakdown = HIGH RISK
What Good Looks Like: Proper Sub-Merchant Governance
When a platform openly operates as an aggregator and implements proper controls, we can assess and manage the risk. Strong governance demonstrates institutional commitment to sub-merchant oversight and regulatory compliance.
This is the acceptable path forward for legitimate payment facilitators.
Documentation Package for Compliant Aggregators
Category
Requirements
Business Registration
Registered as a payment facilitator with Visa and Mastercard
Registration numbers and status verifiable
Complies with card network reporting requirements
If operating across multiple states, proper money transmitter licenses obtained
Sub-Merchant Underwriting Program
Documented policies for seller onboarding and vetting
Clear underwriting criteria (credit checks, business verification, prohibited categories)
Documented approval workflows with proper oversight
KYC/KYB verification using reputable third-party providers
UBO (Ultimate Beneficial Owner) identification for all sub-merchants
Prohibited business categories clearly defined and enforced
Legal Documentation
Terms of Service clearly state platform facilitates payments for third-party sellers
Seller Agreements explicitly govern sub-merchant relationship
Liability allocation between platform and sellers clearly documented
Compliance with all applicable consumer protection laws
Privacy policies compliant with data protection regulations
Monitoring and Enforcement
Transaction monitoring rules specific to sub-merchants
Fraud detection at both platform and seller levels
Regular reporting on seller-level risk metrics
Clear policies for seller violations
Account suspension and termination procedures documented
Chargeback management with seller liability assignment
Financial and Operational Controls
Proper reserve accounts for covering sub-merchant liability
Chargeback and refund liability properly allocated
Settlement processes comply with card network rules
Proper accounting for platform vs. sub-merchant funds
Tax reporting (1099-K) for sub-merchants
Compliance Infrastructure
Designated compliance personnel for sub-merchant oversight
Regular compliance training for staff
Escalation procedures for seller issues
Documentation of who owns sub-merchant risk
Regular audits of sub-merchant compliance
PCI DSS Compliance
Payment facilitator PCI validation
Sub-merchant PCI compliance program
Proper cardholder data handling
Regular security assessments
Example: Compliant Payment Facilitator Profile
Company: Multi-Vendor Marketplace Inc.
Business Model: E-commerce marketplace connecting sellers with buyers
Payment Facilitation: Registered PayFac with Visa/Mastercard
Transparent Operations:
"We operate a marketplace platform that enables small businesses to sell products online. We facilitate payment acceptance for our sellers and are registered as a payment facilitator with Visa and Mastercard. We underwrite each seller, monitor transactions for fraud and policy violations, and maintain full compliance with card network rules."
Sub-Merchant Program:
All sellers complete business verification before approval
KYC/KYB checks using Jumio and LexisNexis
Prohibited categories enforced (no firearms, adult content, etc.)
Ongoing transaction monitoring with velocity checks and fraud rules
Monthly reviews of high-risk seller accounts
Clear termination policy for violations
Financial Structure:
Platform keeps 10% commission on transactions
Sellers receive 90% of sale price minus payment processing fees
Platform maintains reserve account for chargeback liability
Proper tax reporting (1099-K) for all sellers
Compliance:
Designated VP of Compliance with team of 5
Annual PCI DSS validation as payment facilitator
Regular audits by external firm
Compliance training for all staff quarterly
Seller compliance reviews every 6 months
This profile represents an acceptable aggregator with proper governance.
The key differences from hidden aggregators:
Registration: Properly registered with card networks
Underwriting: Vets all sub-merchants before approval
Monitoring: Active transaction monitoring and fraud controls
Governance: Clear compliance ownership and resources
Common Misses: Where Underwriting Breaks Down
Understanding where underwriting typically fails helps prevent onboarding hidden aggregators.
Miss #1: Single Entity Assumption
The Error: Treating the platform as one merchant without investigating who else gets paid through their infrastructure.
What happens: Underwriter reviews business documents showing a registered LLC with clear ownership. Financial statements show revenue. Business model description sounds like direct sales. Documents all check out.
What's missed: The LLC is a platform entity. Actual sales are made by hundreds of unvetted sellers. The LLC just facilitates payments and takes a commission.
The Fix: Always ask: "Who else gets paid through this platform?"
Required follow-up questions:
Are any transactions paid out to accounts other than your primary business account?
Do any third parties sell through your platform?
Can others create accounts and sell independently?
Does anyone besides your company receive funds from customer payments?
Testing protocol: Request 6 months of bank statements and payment processor reports. Look for systematic splits or payments to third parties.
Miss #2: Surface-Level Documentation Review
The Error: Accepting Terms of Service and business descriptions at face value without testing actual functionality.
What happens: Terms of Service reviewed, look clean. Business description says "e-commerce company." Underwriter checks boxes and approves.
What's missed: Terms of Service are written to obscure aggregator operations. The actual website has "Become a Seller" registration, seller dashboards, and commission structures visible to users.
The Fix: Test the actual platform functionality. Don't rely solely on static documents.
Testing protocol:
Navigate the website as a potential seller
Look for registration paths beyond customer accounts
Request demo access to admin panel
Test all user-facing functionality
Compare what's documented vs. what's built
Miss #3: Technical Blind Spots
The Error: Focusing only on business documentation without examining payment routing, technical infrastructure, or API configurations.
What happens: Underwriter reviews formation documents, business licenses, ownership structure. Everything documented properly. Approved.
The Fix: Technical review is mandatory for any platform or software company.
Testing protocol:
Review payment processor account setup and configurations
Request API documentation
Analyze database schemas if accessible
Check for marketplace-specific technologies (Stripe Connect, Adyen for Platforms)
Review hosting and infrastructure for multi-tenant patterns
Miss #4: Incomplete Ecosystem Mapping
The Error: Only reviewing the primary domain without mapping related properties, subdomains, or affiliated entities.
What happens: Underwriter reviews company.com. Looks like a standard e-commerce site. Approved.
What's missed: sellers.company.com exists separately with full seller onboarding and management. Multiple seller storefronts operate on seller-name.company.com subdomains. Entire seller infrastructure hidden from primary domain review.
The Fix: Comprehensive ecosystem mapping is required. Map ALL domains, subdomains, and related entities before approval.
Testing protocol:
DNS and subdomain enumeration
WHOIS lookups for related domains
Reverse IP lookups to find other properties on same infrastructure
Entity relationship mapping to find affiliated companies
Review historical domain usage via Wayback Machine
Documentation requirement: All merchant risk assessments must include an "Ecosystem" section mapping all storefronts, domains, and subdomains operated by the same entity or people.
Miss #5: Ignoring Revenue Model Reality
The Error: Accepting business model descriptions without analyzing actual revenue sources and financial flows.
What happens: Application says "e-commerce business." Revenue seems reasonable. Approved.
What's missed: 80% of revenue is "platform fees" charged to sellers. Only 20% is from direct product sales. The business model is payment facilitation, not direct sales.
The Fix: Require detailed revenue breakdown and reconciliation with transaction volumes.
Testing protocol:
Request financial statements with revenue broken down by source
Compare payment processor transaction volume to reported revenue
Analyze unit economics (what comes in, what goes out, to whom?)
Review growth strategy (seller acquisition vs. customer acquisition?)
If transaction volume greatly exceeds revenue, investigate the gap
Your First Questions: The Critical Inquiry
When evaluating any potential aggregator, these questions must be answered definitively before proceeding:
Payment Flow Questions
"When a customer makes a payment, where does the money go?"
Acceptable: "It comes to our business bank account, and we keep it (minus our costs)."
Red flag: "It goes to our account, then we split it to sellers" or "It routes to different accounts depending on the seller."
"Show me 6 months of bank statements for all accounts that receive any customer payment funds."
Look for: systematic splits, payments to third parties, "seller payout" labels
"Do any third parties besides your company receive money from customer payments?"
Acceptable: "No, only our company."
Red flag: "Yes, our sellers/vendors/partners receive their portion."
Infrastructure Questions
"Can anyone besides your employees create accounts and start selling on your platform?"
Acceptable: "No, only we sell. Customers create accounts to purchase."
Red flag: "Yes, sellers can sign up" or "Our partners can onboard."
"Show me every registration workflow on your website and any related domains."
"Are there any related companies, affiliated entities, or businesses under common ownership or management?" - Map: complete corporate structure and all related properties
Documentation Questions
"Provide your Terms of Service, and any separate agreements for sellers, vendors, or partners." - Look for: seller agreements, marketplace rules, multi-party transaction structure
"Have you ever operated as a marketplace, payment facilitator, or aggregator?" - If yes: "Are you registered with Visa/Mastercard? Provide registration details." - If no: "Can you prove you don't facilitate payments for third parties?"
The Burden of Proof Question
"What evidence proves you are NOT facilitating payments for third parties?"
Shift the burden. Require documentation demonstrating direct merchant operations:
Single beneficiary for all customer payments (bank statements)
No seller/vendor registration capabilities (platform demonstration)
No commission or revenue share language (Terms of Service)
No third-party fulfillment or payout routing (order flow documentation)
All people processing orders are employees (org chart and payroll verification)
If the merchant cannot provide clear evidence of direct operations, decline the application pending further investigation.
Ballerine's Role
Ballerine provides the infrastructure to make this complex assessment manageable: automated ecosystem discovery, infrastructure pattern detection, and continuous merchant monitoring. But the foundational knowledge in this guide gives you the expertise to ask the right questions, identify the red flags, and protect your payment processing business while enabling legitimate direct merchants and properly governed payment facilitators.
The bottom line: Where do you draw the line between direct merchant and hidden aggregator? At the point where the business's infrastructure, as evidenced by payout patterns, seller tools, and technical architecture, shifts from direct sales to facilitating transactions for others. Follow the money, test the infrastructure, and let functional reality guide your decision.
How payment and risk teams can identify hidden sub-merchant infrastructure, map ecosystem complexity, and distinguish direct merchants from disguised aggregators before portfolio risk escalates.
The riskiest sub-merchant is the one nobody admits exists.
Some platforms are just aggregators in disguise.
When a merchant approaches you for payment processing claiming to sell products or services directly to consumers, the complexity isn't in evaluating their product quality or market position. It's in determining whether they're operating as the direct merchant they claim to be or whether they've built infrastructure that enables dozens or hundreds of other sellers to transact through their payment rails. Unlike most merchant categories where you verify business legitimacy and fraud controls, potential aggregators require you to become a functional analyst, mapping technical infrastructure and payment flows to identify whether the business crosses the line from direct sales to payment facilitation.
This guide walks you through the complete assessment framework we use at Ballerine to evaluate potential aggregator-within-aggregator scenarios and distinguish legitimate direct merchants from disguised payment facilitators.
Understanding the Aggregator-Within-Aggregator Challenge
The Regulatory Challenge
The payment facilitation industry exists in a defined regulatory space with clear card network rules and compliance obligations. Payment facilitators (PayFacs) and Independent Sales Organizations (ISOs) that onboard sub-merchants must register with card networks, implement sub-merchant underwriting programs, and maintain ongoing monitoring. These requirements are well-established.
The challenge for compliance teams emerges when merchants deliberately obscure their true business model, using direct merchant language and single-entity presentations while operating functionally as aggregators. This creates three critical problems:
Regulatory Exposure: When you underwrite a merchant as a direct seller but they're actually facilitating payments for unvetted sub-merchants, you inherit liability for those hidden third parties. Card network rules require visibility into all parties in the payment chain.
Risk Concentration: A single merchant relationship can expose your portfolio to hundreds of unvetted businesses. One compliance failure, fraud pattern, or regulatory violation by any sub-merchant creates liability for your organization.
Portfolio Integrity: Hidden aggregators undermine portfolio risk modeling. Your risk assessments assume you're evaluating discrete businesses, not networks of unknown sellers operating under false pretenses.
How Platforms Hide Aggregator Operations
Following the expansion of e-commerce infrastructure and marketplace platforms, the techniques for disguising aggregator operations have become sophisticated. Operators use various structures to obscure sub-merchant activity:
Clean Presentation Layer: The merchant onboarding presents spotless business documentation showing a single legal entity with clear ownership, straightforward operations, and direct sales claims. All initial documentation reviews pass standard underwriting checks.
Technical Obfuscation: Payment flows split to multiple beneficiaries through backend configurations invisible during standard document review. Seller tools exist behind authentication walls. Sub-merchant onboarding happens on separate domains or subdomains not disclosed during underwriting.
Legal Structure Gaming: Terms of service carefully avoid explicit aggregator language while enabling all the functionality. They may call sub-merchants "partners," "affiliates," or "collaborators" rather than "sellers" or "vendors."
The Stakes
The financial and regulatory consequences of missing these patterns include:
Card Network Fines: Visa and Mastercard impose fines for unregistered payment facilitation activity. These can reach millions of dollars depending on transaction volume.
Banking Relationship Termination: When acquiring banks discover unregistered aggregation, they terminate the merchant relationship, often immediately.
Regulatory Action: FinCEN and state regulators can pursue money transmission violations when platforms facilitate payments without proper licensing.
Liability for Sub-Merchant Misconduct: Chargebacks, fraud losses, and regulatory violations by unknown sub-merchants become your exposure.
Key takeaway: Even if a merchant claims to be "just a direct seller" or presents as a single business entity, functional analysis determines regulatory classification. Your underwriting must identify facilitation patterns to maintain payment compliance and avoid inheriting unmanaged risk.
The Regulatory Context
Federal and Card Network Framework
Before examining specific merchant characteristics, understand the legal frameworks that apply when platforms facilitate payments for others:
Card Network Rules
Visa and Mastercard maintain Payment Facilitator Registration Programs. Any entity that enables sub-merchants to accept card payments must:
Register with the card networks as a payment facilitator
Implement sub-merchant onboarding and underwriting programs
Maintain ongoing monitoring of sub-merchant activity
Report sub-merchant data to the networks
Accept liability for sub-merchant violations
Operating as a de facto payment facilitator without registration violates card network rules and triggers fines, enforcement actions, and potential termination of payment processing relationships.
FinCEN Requirements
The Financial Crimes Enforcement Network Customer Due Diligence Requirements mandate that money services businesses identify beneficial owners of all parties in payment flows. When platforms facilitate payments for others, those third parties must be identified and verified.
Platforms that split payments to multiple beneficiaries may trigger money transmitter licensing requirements at the state level. Requirements vary by state but generally apply when the platform holds, transfers, or disburses funds on behalf of others.
PCI DSS Obligations
PCI DSS requires payment facilitators to maintain separate validation for sub-merchants. When a merchant presents as direct but operates as an aggregator, they often lack proper PCI compliance programs for their hidden sub-merchants, creating data security exposure.
State Money Transmitter Laws
Many states require money transmitter licenses for payment facilitation activity. Platforms that receive customer payments and disburse funds to sellers are transmitting money. Operating without required state licenses creates regulatory violations and potential criminal liability.
Industry-Specific Considerations
Certain industries have higher aggregator risk:
Marketplace and Multi-Vendor Platforms: SaaS platforms serving e-commerce sellers, event ticketing platforms, rental marketplaces, and service provider networks frequently enable payment facilitation as a core feature.
Franchise and Network Models: Franchise systems, MLM organizations, and reseller networks often centralize payment processing for distributed seller networks.
Gig Economy Platforms: Platforms connecting service providers with customers often process payments on behalf of independent contractors who function as sub-merchants.
For fintech and marketplace companies, these patterns are especially common.
The Complete Assessment Framework
1. Payout Flow Analysis
Why it matters: Payment flows reveal what business documentation conceals. When money systematically splits to multiple bank accounts, routes through different entities, or follows seller-specific logic, you're looking at sub-merchant activity regardless of what the platform claims.
This is the single most reliable indicator of hidden aggregation. Business documents lie. Payment flows don't.
High-Risk Payout Patterns
Systematic Split Payments
Payments from customers route to a primary account, then automatically split to multiple beneficiary accounts
Different bank accounts receive payouts for different transaction subsets
Payout logic based on product ID, seller ID, or transaction metadata
Why this is critical risk: Automated payment splitting to third parties is the defining characteristic of payment facilitation. This pattern has no legitimate explanation in direct merchant operations.
Multiple Beneficiary Accounts
Transaction settlements flow to more than one legal entity
Different days of the week or different product categories settle to different accounts
Account beneficiaries include individuals or businesses not disclosed during underwriting
Why this is critical risk: Direct merchants settle to a single beneficiary account. Multiple beneficiaries indicate multiple economic interests in the transactions, meaning sub-merchant activity.
Revenue Share Settlement Logic
Payout amounts suggest commission or revenue share calculations (e.g., 70% to one account, 30% to another)
Settlement amounts don't match gross transaction values (indicating platform is taking a cut)
Payouts occur on different schedules for different recipients
Why this is high risk: Revenue sharing is how aggregators compensate sub-merchants. This settlement structure indicates facilitation.
Third-Party Payment Processor Relationships
The merchant uses payment processors known for serving marketplaces or multi-vendor platforms (Stripe Connect, Adyen for Platforms, PayPal Commerce Platform)
Processor integration includes marketplace or split payment features
API documentation references "connected accounts" or "sub-merchant accounts"
Why this is high risk: Merchants don't use sophisticated marketplace payment infrastructure unless they're operating marketplaces.
Acceptable Payout Patterns
Single Beneficiary Settlement
All transaction settlements flow to one bank account
Account beneficiary matches the legal entity underwritten
Consistent settlement schedule and logic
No Split Payment Logic
Payment processor configurations show standard merchant account setup
No references to sub-accounts, connected accounts, or split settlements
API integrations are standard merchant integrations, not marketplace tools
Transparent Payment Processor Relationships
Uses payment processors appropriate for direct merchant operations
Can provide complete documentation of payment processor setup
No hidden or undisclosed processor relationships
What to Request from Merchant
Documentation category
Required materials
Bank Statements
Last 6 months of statements for all business accounts
Settlement reports from all payment processors
Explanation of any accounts showing disbursements to third parties
Payment Processor Configuration
Complete processor account setup documentation
API integration specifications
List of all processor accounts (current and historical)
Settlement schedule and logic documentation
Payout Logic Documentation
Technical documentation of payment routing
If any payment splits occur, complete explanation of why
List of all bank accounts that receive any portion of customer payments
Reconciliation Reports
Sample transaction-to-settlement reconciliation
Documentation explaining any differences between transaction amounts and settlement amounts
Explanation of any fees or splits
Investigation Steps
Bank Statement Analysis
Analyze 6 months of bank statements looking for:
Consistent patterns of outgoing transfers to third parties
Transfers labeled as "payout," "seller payment," "vendor payment," "commission," etc.
Transfers that correlate with incoming payment processor settlements
Multiple accounts receiving portions of the same deposit batch
Payment Processor Deep Dive
Request complete access to payment processor configurations:
Review all account settings
Check for enabled marketplace or split payment features
Review API integration code if accessible
Verify processor account type (standard merchant vs. platform/marketplace account)
Transaction Flow Mapping
For a sample transaction, map the complete flow:
Customer payment: $100
Payment processor receives: $100
Processor fee: $3
Settlement to merchant: $97
Does merchant keep $97 or split it? This is the critical question.
If the merchant keeps the full settlement (minus their own business expenses), they're a direct merchant.
If the merchant systematically splits settlement to third parties, they're facilitating payments.
Comparative Analysis
Compare their payment flows to known direct merchants in the same industry:
Do other direct merchants in this space use these payment processors?
Do other direct merchants have similar settlement patterns?
Are there industry norms this merchant deviates from?
Merchant Assessment Checklist
Settlement Characteristics
All settlements flow to single beneficiary account matching underwritten entity
No systematic splits to third-party accounts
Settlement amounts match transaction values (minus standard processor fees)
No revenue-share or commission logic in settlement patterns
Payment Processor Configuration
Standard merchant account type (not marketplace or platform account)
No split payment or connected account features enabled
Processor relationship matches direct merchant profile
Complete transparency in processor setup
Documentation Completeness
Can provide all bank statements for all business accounts
Can explain all outgoing transfers from settlement accounts
Transaction-to-settlement reconciliation is straightforward
No undisclosed payment routing or third-party disbursements
Red flag threshold:
ANY systematic split payments to third parties = CRITICAL RISK (Automatic decline without acceptable explanation)
Multiple beneficiary accounts = CRITICAL RISK
Revenue share settlement logic = CRITICAL RISK
Marketplace payment processor features enabled = HIGH RISK
Inability to explain settlement patterns = HIGH RISK
For merchant acquiring platforms, automated payout flow analysis during underwriting prevents onboarding hidden aggregators.
2. Onboarding Infrastructure Investigation
Why it matters: The systems a platform builds reveal their true business model. Direct merchants need customer onboarding. Aggregators need seller onboarding. The presence of seller onboarding infrastructure, regardless of what they call it, indicates sub-merchant operations.
High-Risk Onboarding Patterns
Self-Service Seller Registration
Public-facing registration forms where third parties can sign up to sell
Automated account creation without manual review
"Become a Seller," "Start Selling," "Partner with Us," or "Join Our Marketplace" flows
Registration forms collect business information from multiple entities
Why this is critical risk: Self-service seller onboarding is the hallmark of marketplace platforms. Direct merchants don't need this infrastructure.
Multi-Entity Information Collection
During registration, the platform collects:
Business registration documents from multiple companies
Tax identification numbers (EIN/SSN) from different parties
Bank account information from various entities
Individual identity verification for multiple people
Why this is critical risk: Direct merchants collect this information once, about themselves. Collecting it repeatedly from different parties indicates sub-merchant onboarding.
Tiered Account Structures
Different user roles: "Admin," "Seller," "Vendor," "Partner"
Hierarchical permissions showing some users can manage others
"Store owner" or "shop manager" roles separate from platform admin
Documentation referring to "your sellers" or "your vendors"
Why this is high risk: Tiered account structures with seller-specific roles serve no purpose in direct merchant operations. They exist to manage sub-merchant networks.
Identity Verification Infrastructure
Integration with KYC/KYB providers (Jumio, Onfido, Trulioo) for ongoing verification
Repeated identity verification workflows (not just at initial company sign-up)
Documentation indicating verification occurs for "each seller" or "each vendor"
Why this is high risk: Robust identity verification infrastructure for ongoing account creation indicates systematic onboarding of third parties.
Business Document Collection Systems
Automated systems for collecting and storing business licenses, certificates, permits
Document requirements listed for "each seller" or "each vendor"
Approval workflows showing review of business documents before account activation
Why this is high risk: Direct merchants submit their own documents once. Systems built to collect documents from many parties indicate sub-merchant operations.
Acceptable Onboarding Patterns
Single-Entity Onboarding
Company completes one onboarding process at initial setup
No ongoing onboarding for additional parties
Any additional users are employees of the underwritten entity
Tiered account structures with seller-specific roles = HIGH RISK
Collects business information from multiple entities = CRITICAL RISK
KYC integration for ongoing third-party verification = HIGH RISK
Cannot demonstrate registration flow transparency = HIGH RISK
3. Terms of Service and Legal Language
Why it matters: Terms of service drafters carefully avoid explicitly stating "we're an aggregator" or "we facilitate payments for sub-merchants." But legal documents must still describe what the platform actually does. Reading for functional capabilities rather than explicit labels reveals aggregator infrastructure.
The presence of certain legal provisions has no explanation except multi-party payment operations.
High-Risk Legal Language
Seller, Vendor, or Partner Provisions
Terms of Service includes sections titled:
"For Sellers"
"Vendor Agreement"
"Partner Terms"
"Marketplace Rules"
"Sub-Merchant Terms"
Or references such as:
"our sellers"
"merchants on our platform"
"third-party sellers"
"independent vendors"
Why this is critical risk: Direct merchants don't need seller agreements. These provisions exist to govern sub-merchant relationships.
Commission and Revenue Share Language
"We charge sellers X% per transaction"
"Commission structure"
"Revenue split"
"Platform fee charged to vendors"
"Service fee on sales"
"We retain X% and pay Y% to the seller"
Why this is critical risk: Commission structures are how aggregators make money. Direct merchants sell products/services and keep revenue. Platforms that "charge sellers" are facilitating their transactions.
Third-Party Liability Disclaimers
"We are not responsible for seller conduct"
"Products are sold by independent vendors"
"We do not guarantee third-party seller performance"
"Disputes should be resolved directly with the seller"
"Sellers are responsible for their own tax obligations"
Why this is high risk: These disclaimers exist to limit platform liability for sub-merchant actions. Direct merchants can't disclaim responsibility for their own conduct.
Seller Performance Policies
Seller performance standards (shipping time requirements, response rates)
Seller rating and review systems
Account suspension or termination for seller policy violations
"Seller Code of Conduct"
Why this is high risk: Performance management systems govern third-party behavior. Direct merchants don't need to enforce policies against themselves.
Indemnification Protecting Platform from Seller Actions
"Sellers indemnify the platform for claims arising from their products"
"Sellers are solely responsible for compliance with applicable laws"
"Platform is not liable for seller intellectual property violations"
Why this is high risk: Indemnification clauses shift liability from platform to sellers, which only makes sense when sellers are separate entities.
Payment Processing Language
"We process payments on behalf of sellers"
"We facilitate transactions between buyers and sellers"
"Payment will be split between the platform and seller"
"We hold funds in escrow and release to sellers upon completion"
Why this is critical risk: This is explicit payment facilitation language.
Multi-Party Transaction Structure
Terms describe transactions as involving platform, buyer, and seller (three parties)
Different warranties apply to platform services vs. seller products
Separate refund policies for platform fees vs. seller proceeds
Why this is high risk: Three-party transaction structure indicates marketplace operations, not direct sales.
Acceptable Legal Language
Single-Entity Transaction Structure
Terms describe transactions as between the company and customer (two parties)
Company is responsible for all products/services sold
No references to third-party sellers or vendors
Direct Seller Warranties
Company warrants product quality, service delivery, compliance
No disclaimers of responsibility for third-party conduct
Clear accountability for all customer-facing operations
Standard E-Commerce Language
Privacy policy covers company data collection only
Refund policy applies to all products uniformly
Customer support provided by company
No Revenue Split References
No commission structures
No language about "fees charged to sellers"
All revenue discussion relates to customer pricing
What to Request from Merchant
Documentation category
Required materials
Terms of Service
Current and all historical versions
Any separate seller, vendor, or partner agreements
Any marketplace rules or policies
Privacy Policy
Current version
Does it reference multiple parties in data collection?
Refund/Return Policy
Who processes refunds?
Are refunds handled uniformly or per-seller?
Business Model Documentation
How does the company describe its operations in legal documents?
Any contracts with “sellers” or “vendors”
Intellectual Property Policies
Who owns content uploaded to platform?
Any provisions about seller-uploaded content?
Investigation Steps
Keyword Search
Search Terms of Service and related documents for:
"seller" / "sellers"
"vendor" / "vendors"
"partner" / "partners"
"merchant" / "merchants"
"commission"
"revenue share" / "revenue split"
"platform fee"
"third party" / "third-party"
"marketplace"
"facilitate"
"on behalf of"
Document every instance and surrounding context.
Section Analysis
Read carefully for:
Who are the parties to transactions?
Who bears liability for what aspects?
How is money described as flowing?
Are there provisions governing third-party behavior?
Historical Comparison
If the company has been operating for several years:
Request historical versions of Terms of Service
Look for changes over time
Did seller provisions get added later?
Were marketplace references removed before applying for processing?
This reveals attempts to hide aggregator operations during underwriting.
Legal Entity Cross-Reference:
Does the legal entity in Terms of Service match the entity applying for processing?
Are there references to multiple legal entities?
Do seller agreements reference different entities?
Competitor Comparison
Compare Terms of Service to:
Known direct merchants in the industry
Known marketplace platforms in the industry
Where does this merchant's language align?
Merchant Assessment Checklist
Transaction Structure
Terms describe two-party transactions (company and customer)
No references to sellers, vendors, or third-party merchants
Company assumes full responsibility for all products/services
No liability disclaimers related to third-party conduct
Revenue Model
No commission, revenue share, or fee-to-sellers language
All revenue discussion relates to customer pricing
No payment facilitation language
No descriptions of splitting or holding funds for others
Legal Accountability
Company provides all warranties and guarantees
No indemnification from sellers to platform
Customer service and support provided by company
No seller performance policies
Documentation Consistency
Terms of Service consistent with business model presented during underwriting
No hidden seller or vendor agreements
Historical versions show consistent positioning
Legal entity matches application
Red flag threshold:
References to "our sellers" or similar language = CRITICAL RISK
Commission or revenue share provisions = CRITICAL RISK
Seller agreements or marketplace rules exist = CRITICAL RISK
Three-party transaction structure = HIGH RISK
Indemnification from sellers to platform = HIGH RISK
Payment facilitation language = CRITICAL RISK
4. Seller Tools and Platform Capabilities
Why it matters: The functionality built into a platform reveals what operations it enables. Platforms don't accidentally build sophisticated seller dashboards, inventory management systems, or order routing tools. These capabilities exist for specific purposes.
If those purposes include enabling third parties to manage their own sales operations, you're looking at aggregator infrastructure.
Performance metrics for individual sellers (conversion rates, average order value)
Sales reports broken down by seller
Revenue tracking per seller
Tools for sellers to analyze their own performance
Why this is critical risk: Sellers need dashboards. Direct merchants have one dashboard for their entire business. Multiple seller dashboards indicate sub-merchant operations.
Inventory Management for Multiple Parties
Individual sellers can add/edit their own product listings
Each seller manages their own inventory levels
Products are associated with specific seller accounts
Bulk upload tools for seller product catalogs
Why this is critical risk: If different parties control different portions of inventory, they're different merchants.
Order Fulfillment Routing
Orders route to different fulfillment locations based on seller
Sellers receive order notifications independently
Shipping and tracking managed per-seller
Different sellers can have different shipping policies
Why this is high risk: Order routing to different entities for fulfillment indicates those entities are the actual merchants.
Seller Communication Tools
Messaging systems allowing buyer-seller communication
Seller support ticket systems separate from platform support
Tools for sellers to respond to customer inquiries about their products
Review and rating systems for individual sellers
Why this is high risk: When customers need to contact specific sellers rather than the platform, those sellers are the actual merchants.
Payout and Financial Management Tools
Sellers can view their pending payouts
Financial dashboards showing seller earnings
Tools to manage bank account information for receiving payments
Tax document generation per seller (1099s, etc.)
Why this is critical risk: Individual payout tracking and tax document generation proves multi-party financial operations.
Seller Onboarding and Account Management
Sellers can update their business information
Tools to manage business verification documents
Seller identity re-verification workflows
Account settings specific to seller operations
Why this is high risk: Ongoing seller account management tools serve no purpose except managing sub-merchant relationships.
Storefront Customization
Sellers can customize their "shop" or "store" within the platform
Individual branding per seller
Different visual themes or layouts per seller
Custom domain or subdomain options for sellers
Why this is high risk: Storefront customization enables sellers to present branded experiences, indicating they're independent merchants using shared infrastructure.
Acceptable Platform Capabilities
Single Admin Dashboard
One dashboard showing complete business operations
Managed by employees of the underwritten entity
All functionality relates to company's direct operations
Unified Inventory Management
All products managed by company
No seller-specific inventory controls
Employees manage all listings
Centralized Order Processing
All orders processed by company
Single fulfillment workflow
Company handles all customer communication
Customer-Facing Tools Only
Customer accounts for making purchases
Order tracking for customer convenience
Customer support managed by company
Internal User Management
Additional users are employees
Permissions relate to job functions (customer service, marketing, logistics)
No seller or vendor management capabilities
What to Request from Merchant
Documentation category
Required materials
Platform Documentation
Complete feature list
User guides for all functionality
Screenshots of all user interface areas
API documentation
Demo Access
Full admin panel access
Access to all user types if multiple exist
Ability to navigate all features
Technical Architecture
System architecture diagrams
Database schemas
Third-party integrations list
Seller Tools Documentation
If any seller-facing tools exist, complete documentation
Explanation of purpose for each feature
Who uses these tools?
Testing Protocol
Comprehensive Platform Review
Request demo access and systematically review:
Main Dashboard
What information is displayed?
Are there sections for different sellers?
Can you filter or segment by any seller-related dimension?
Product/Service Management
Who can add new listings?
Are listings associated with specific sellers?
Can different users manage different subsets of products?
Order Management
How are orders displayed?
Do orders route to different parties?
Who fulfills orders?
Financial/Reporting Section
Are there financial breakdowns by seller?
Can individual sellers view their own earnings?
Are there payout management tools?
User Management
What user types exist?
Can admin create seller accounts?
What permissions can sellers have?
Communication Tools
How do customers contact the business?
Is there seller-specific messaging?
Who responds to customer inquiries?
API Documentation Review
If API documentation is available:
Look for endpoints related to:
/sellers/
/vendors/
/merchants/
/payouts/
/sub-accounts/
Review data models:
Do data structures include seller_id, vendor_id, merchant_id fields?
Are transactions associated with specific sellers?
Integration capabilities:
Can third parties integrate to manage their operations?
Technical Pattern Recognition
Look for architectural patterns common in marketplace platforms:
Multi-tenancy (different sellers operating in isolated environments)
Role-based access control with seller-specific permissions
Seller-specific data isolation
Sub-account or connected account structures
Competitive Analysis
Compare platform capabilities to:
Known marketplace platforms in the industry (Etsy, Amazon Marketplace, Shopify Plus with multi-vendor capabilities)
Known direct merchant platforms (standard e-commerce sites)
Where does this merchant's technical sophistication align?
Merchant Assessment Checklist
Dashboard and Analytics
Single dashboard for entire business operations
No seller-specific performance metrics
All analytics relate to company's direct sales
No tools for third parties to view their own performance
Inventory and Product Management
All products managed by company employees
No seller-specific inventory controls
Unified product catalog
No tools for third parties to manage their own listings
Order Processing
All orders fulfilled by company
Unified order management workflow
No routing to different entities based on product or seller
Company handles all customer communication
Financial Tools
No seller-specific financial dashboards
No individual payout tracking for third parties
No tax document generation for multiple parties
All financial management relates to company operations
User Management
Users are employees of the underwritten entity
No seller or vendor account types
Permissions relate to internal job functions
No third-party account management
Red flag threshold:
Seller dashboards exist = CRITICAL RISK
Individual sellers can manage inventory = CRITICAL RISK
Order routing to different entities = HIGH RISK
Seller financial management tools = CRITICAL RISK
Messaging between buyers and specific sellers = HIGH RISK
Storefront customization per seller = HIGH RISK
For banking compliance teams, thorough technical review during underwriting prevents post-onboarding discoveries of hidden aggregator infrastructure.
5. Ecosystem Mapping and Domain Architecture
Why it matters: Single-domain evaluation misses the complexity of distributed operations. Hidden aggregators often operate seller-facing infrastructure on separate domains, subdomains, or white-labeled properties not disclosed during underwriting.
URL structure like: seller-name.platform.com or platform.com/seller-name
Each subdomain or path shows different seller branding
Different product catalogs per subdomain
Different contact information per subdomain
Why this is critical risk: Individual seller storefronts indicate marketplace operations. Each subdomain represents a different merchant using shared payment infrastructure.
Separate Seller Portal Domain
Different domain for seller login and management (e.g., sellers.platform.com, partner-portal.platform.com)
Seller onboarding occurs on separate domain
Seller resources and documentation on different property
Why this is high risk: Segregating seller-facing infrastructure suggests intentional obscuring of aggregator operations. The separation serves to hide sub-merchant activity from primary brand presentation.
White-Label Seller Storefronts
Sellers can use custom domains pointing to platform infrastructure
DNS records show multiple domains resolving to same platform servers
Why this is critical risk: White-labeling enables sellers to present as independent businesses while using platform payment facilitation, obscuring the aggregation relationship.
Multiple Properties Under Same Control
Different domains owned by same entity or related entities
Shared infrastructure (same hosting, same CMS, same payment processors)
Cross-linking or shared resources between properties
Why this is high risk: Multiple related properties can indicate distributed seller operations or attempts to segment high-risk activities across different merchant accounts.
Ecosystem Mapping Requirements
According to regulatory best practices and Mastercard standards, merchant risk assessments must include an "Ecosystem" section mapping:
All domains and subdomains operated by the same entity or people
Related websites sharing ownership, management, or infrastructure
White-label storefronts powered by the platform
Any properties where products from the merchant's catalog appear
This mapping reveals the true scope of operations and identifies hidden sub-merchant activity distributed across multiple properties.
What to Request from Merchant
Documentation category
Required materials
Complete Domain List
All domains owned or operated by the company
All subdomains in use
Any white-label or custom domain capabilities provided to third parties
Infrastructure Documentation
Hosting providers for all properties
Shared infrastructure across domains
DNS configuration documentation
Related Entity Disclosures
Any related companies, subsidiaries, or affiliated entities
Multiple undisclosed domains discovered = HIGH RISK
Infrastructure indicates marketplace platform = HIGH RISK
Attempts to hide properties or related entities = CRITICAL RISK
6. Revenue Model Deconstruction
Why it matters: How a merchant makes money reveals their true business model more reliably than any self-description. Platform claims about being a "direct seller" or "service provider" become meaningless when revenue comes from commissions on third-party sales.
Revenue model analysis requires financial documentation, not just business descriptions.
High-Risk Revenue Models
Commission-Based Revenue
Primary revenue from "fees charged to sellers"
"Platform fee" or "service fee" as percentage of third-party sales
Revenue scales with number of sellers and their transaction volume
Why this is critical risk: Commission-based revenue models are how aggregators operate. The platform facilitates transactions and takes a cut. This is payment facilitation.
Transaction Volume Revenue Share
Revenue agreements with payment processors based on facilitated transaction volume
"We earn X% of payment processing volume"
Revenue increases as sellers process more transactions
Platform has financial incentive for sellers to transact more
Why this is critical risk: Revenue that scales with facilitated transaction volume indicates the platform's business is payment facilitation, not direct sales.
Seller Subscription with Small Share of Revenue
Sellers pay monthly/annual subscription to platform
BUT: Platform also takes commission on transactions
If transaction volume is significantly higher than revenue, where does the difference go? This pattern suggests the merchant is facilitating transactions and keeping only a commission.
Acceptable explanation: "We're a high-volume, low-margin business. Transaction volume is $1M, our cost of goods sold is $800K, gross margin is $200K."
Unacceptable explanation: "Transaction volume is $1M, we keep $200K as platform fees, $800K goes to sellers."
The second scenario is payment facilitation.
Unit Economics Analysis
Request documentation of unit economics:
What is sold?
What does the customer pay?
What does the company keep?
What costs exist in delivering the product/service?
For a direct merchant:
Customer pays: $100
Company keeps: $100 (full sale amount)
Company pays for: product cost $60, shipping $10, operations $20
If growth plans focus on seller acquisition and seller transaction volume, you're looking at an aggregator.
Competitive Benchmarking
Research financial models of similar companies:
What are revenue multiples in this industry?
What are typical margins?
How do known direct merchants vs. known marketplaces monetize?
Merchant Assessment Checklist
Revenue Composition
Over 80% of revenue from direct sales of company's products/services
No commission or platform fees charged to sellers
No transaction-based revenue from facilitating third-party sales
Any affiliate revenue is clearly disclosed and <20% of total
Financial Alignment
Transaction volume matches reported revenue (accounting for standard margins)
Financial statements show direct sales business model
Unit economics demonstrate direct merchant operations
No revenue share agreements with sellers
Growth Strategy
Growth plans focus on direct customer acquisition
Revenue scales with direct sales, not seller network growth
Company success not dependent on seller transaction volume
No seller acquisition targets or seller volume goals
Documentation Transparency
Can provide complete revenue breakdown
Financial statements clearly show revenue sources
No hidden or unexplained revenue streams
Projections consistent with direct merchant model
Red flag threshold:
Commission-based revenue >20% of total = HIGH RISK
Commission-based revenue >50% of total = CRITICAL RISK
Transaction volume significantly exceeds reported revenue = HIGH RISK
Revenue scales with seller network, not direct sales = HIGH RISK
Freemium model for sellers with transaction-based monetization = CRITICAL RISK
Cannot provide clear revenue source breakdown = HIGH RISK
What Good Looks Like: Proper Sub-Merchant Governance
When a platform openly operates as an aggregator and implements proper controls, we can assess and manage the risk. Strong governance demonstrates institutional commitment to sub-merchant oversight and regulatory compliance.
This is the acceptable path forward for legitimate payment facilitators.
Documentation Package for Compliant Aggregators
Category
Requirements
Business Registration
Registered as a payment facilitator with Visa and Mastercard
Registration numbers and status verifiable
Complies with card network reporting requirements
If operating across multiple states, proper money transmitter licenses obtained
Sub-Merchant Underwriting Program
Documented policies for seller onboarding and vetting
Clear underwriting criteria (credit checks, business verification, prohibited categories)
Documented approval workflows with proper oversight
KYC/KYB verification using reputable third-party providers
UBO (Ultimate Beneficial Owner) identification for all sub-merchants
Prohibited business categories clearly defined and enforced
Legal Documentation
Terms of Service clearly state platform facilitates payments for third-party sellers
Seller Agreements explicitly govern sub-merchant relationship
Liability allocation between platform and sellers clearly documented
Compliance with all applicable consumer protection laws
Privacy policies compliant with data protection regulations
Monitoring and Enforcement
Transaction monitoring rules specific to sub-merchants
Fraud detection at both platform and seller levels
Regular reporting on seller-level risk metrics
Clear policies for seller violations
Account suspension and termination procedures documented
Chargeback management with seller liability assignment
Financial and Operational Controls
Proper reserve accounts for covering sub-merchant liability
Chargeback and refund liability properly allocated
Settlement processes comply with card network rules
Proper accounting for platform vs. sub-merchant funds
Tax reporting (1099-K) for sub-merchants
Compliance Infrastructure
Designated compliance personnel for sub-merchant oversight
Regular compliance training for staff
Escalation procedures for seller issues
Documentation of who owns sub-merchant risk
Regular audits of sub-merchant compliance
PCI DSS Compliance
Payment facilitator PCI validation
Sub-merchant PCI compliance program
Proper cardholder data handling
Regular security assessments
Example: Compliant Payment Facilitator Profile
Company: Multi-Vendor Marketplace Inc.
Business Model: E-commerce marketplace connecting sellers with buyers
Payment Facilitation: Registered PayFac with Visa/Mastercard
Transparent Operations:
"We operate a marketplace platform that enables small businesses to sell products online. We facilitate payment acceptance for our sellers and are registered as a payment facilitator with Visa and Mastercard. We underwrite each seller, monitor transactions for fraud and policy violations, and maintain full compliance with card network rules."
Sub-Merchant Program:
All sellers complete business verification before approval
KYC/KYB checks using Jumio and LexisNexis
Prohibited categories enforced (no firearms, adult content, etc.)
Ongoing transaction monitoring with velocity checks and fraud rules
Monthly reviews of high-risk seller accounts
Clear termination policy for violations
Financial Structure:
Platform keeps 10% commission on transactions
Sellers receive 90% of sale price minus payment processing fees
Platform maintains reserve account for chargeback liability
Proper tax reporting (1099-K) for all sellers
Compliance:
Designated VP of Compliance with team of 5
Annual PCI DSS validation as payment facilitator
Regular audits by external firm
Compliance training for all staff quarterly
Seller compliance reviews every 6 months
This profile represents an acceptable aggregator with proper governance.
The key differences from hidden aggregators:
Registration: Properly registered with card networks
Underwriting: Vets all sub-merchants before approval
Monitoring: Active transaction monitoring and fraud controls
Governance: Clear compliance ownership and resources
Common Misses: Where Underwriting Breaks Down
Understanding where underwriting typically fails helps prevent onboarding hidden aggregators.
Miss #1: Single Entity Assumption
The Error: Treating the platform as one merchant without investigating who else gets paid through their infrastructure.
What happens: Underwriter reviews business documents showing a registered LLC with clear ownership. Financial statements show revenue. Business model description sounds like direct sales. Documents all check out.
What's missed: The LLC is a platform entity. Actual sales are made by hundreds of unvetted sellers. The LLC just facilitates payments and takes a commission.
The Fix: Always ask: "Who else gets paid through this platform?"
Required follow-up questions:
Are any transactions paid out to accounts other than your primary business account?
Do any third parties sell through your platform?
Can others create accounts and sell independently?
Does anyone besides your company receive funds from customer payments?
Testing protocol: Request 6 months of bank statements and payment processor reports. Look for systematic splits or payments to third parties.
Miss #2: Surface-Level Documentation Review
The Error: Accepting Terms of Service and business descriptions at face value without testing actual functionality.
What happens: Terms of Service reviewed, look clean. Business description says "e-commerce company." Underwriter checks boxes and approves.
What's missed: Terms of Service are written to obscure aggregator operations. The actual website has "Become a Seller" registration, seller dashboards, and commission structures visible to users.
The Fix: Test the actual platform functionality. Don't rely solely on static documents.
Testing protocol:
Navigate the website as a potential seller
Look for registration paths beyond customer accounts
Request demo access to admin panel
Test all user-facing functionality
Compare what's documented vs. what's built
Miss #3: Technical Blind Spots
The Error: Focusing only on business documentation without examining payment routing, technical infrastructure, or API configurations.
What happens: Underwriter reviews formation documents, business licenses, ownership structure. Everything documented properly. Approved.
The Fix: Technical review is mandatory for any platform or software company.
Testing protocol:
Review payment processor account setup and configurations
Request API documentation
Analyze database schemas if accessible
Check for marketplace-specific technologies (Stripe Connect, Adyen for Platforms)
Review hosting and infrastructure for multi-tenant patterns
Miss #4: Incomplete Ecosystem Mapping
The Error: Only reviewing the primary domain without mapping related properties, subdomains, or affiliated entities.
What happens: Underwriter reviews company.com. Looks like a standard e-commerce site. Approved.
What's missed: sellers.company.com exists separately with full seller onboarding and management. Multiple seller storefronts operate on seller-name.company.com subdomains. Entire seller infrastructure hidden from primary domain review.
The Fix: Comprehensive ecosystem mapping is required. Map ALL domains, subdomains, and related entities before approval.
Testing protocol:
DNS and subdomain enumeration
WHOIS lookups for related domains
Reverse IP lookups to find other properties on same infrastructure
Entity relationship mapping to find affiliated companies
Review historical domain usage via Wayback Machine
Documentation requirement: All merchant risk assessments must include an "Ecosystem" section mapping all storefronts, domains, and subdomains operated by the same entity or people.
Miss #5: Ignoring Revenue Model Reality
The Error: Accepting business model descriptions without analyzing actual revenue sources and financial flows.
What happens: Application says "e-commerce business." Revenue seems reasonable. Approved.
What's missed: 80% of revenue is "platform fees" charged to sellers. Only 20% is from direct product sales. The business model is payment facilitation, not direct sales.
The Fix: Require detailed revenue breakdown and reconciliation with transaction volumes.
Testing protocol:
Request financial statements with revenue broken down by source
Compare payment processor transaction volume to reported revenue
Analyze unit economics (what comes in, what goes out, to whom?)
Review growth strategy (seller acquisition vs. customer acquisition?)
If transaction volume greatly exceeds revenue, investigate the gap
Your First Questions: The Critical Inquiry
When evaluating any potential aggregator, these questions must be answered definitively before proceeding:
Payment Flow Questions
"When a customer makes a payment, where does the money go?"
Acceptable: "It comes to our business bank account, and we keep it (minus our costs)."
Red flag: "It goes to our account, then we split it to sellers" or "It routes to different accounts depending on the seller."
"Show me 6 months of bank statements for all accounts that receive any customer payment funds."
Look for: systematic splits, payments to third parties, "seller payout" labels
"Do any third parties besides your company receive money from customer payments?"
Acceptable: "No, only our company."
Red flag: "Yes, our sellers/vendors/partners receive their portion."
Infrastructure Questions
"Can anyone besides your employees create accounts and start selling on your platform?"
Acceptable: "No, only we sell. Customers create accounts to purchase."
Red flag: "Yes, sellers can sign up" or "Our partners can onboard."
"Show me every registration workflow on your website and any related domains."
"Are there any related companies, affiliated entities, or businesses under common ownership or management?" - Map: complete corporate structure and all related properties
Documentation Questions
"Provide your Terms of Service, and any separate agreements for sellers, vendors, or partners." - Look for: seller agreements, marketplace rules, multi-party transaction structure
"Have you ever operated as a marketplace, payment facilitator, or aggregator?" - If yes: "Are you registered with Visa/Mastercard? Provide registration details." - If no: "Can you prove you don't facilitate payments for third parties?"
The Burden of Proof Question
"What evidence proves you are NOT facilitating payments for third parties?"
Shift the burden. Require documentation demonstrating direct merchant operations:
Single beneficiary for all customer payments (bank statements)
No seller/vendor registration capabilities (platform demonstration)
No commission or revenue share language (Terms of Service)
No third-party fulfillment or payout routing (order flow documentation)
All people processing orders are employees (org chart and payroll verification)
If the merchant cannot provide clear evidence of direct operations, decline the application pending further investigation.
Ballerine's Role
Ballerine provides the infrastructure to make this complex assessment manageable: automated ecosystem discovery, infrastructure pattern detection, and continuous merchant monitoring. But the foundational knowledge in this guide gives you the expertise to ask the right questions, identify the red flags, and protect your payment processing business while enabling legitimate direct merchants and properly governed payment facilitators.
The bottom line: Where do you draw the line between direct merchant and hidden aggregator? At the point where the business's infrastructure, as evidenced by payout patterns, seller tools, and technical architecture, shifts from direct sales to facilitating transactions for others. Follow the money, test the infrastructure, and let functional reality guide your decision.
.png)
.png){kind=logo}
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.png)
