Lumx accounts can’t be used to process, facilitate, or transmit payments on behalf of any party whose identity or transaction activity isn’t visible to Lumx. Every transaction has to be tied to an onboarded customer acting on their own behalf with their own funds.Documentation Index
Fetch the complete documentation index at: https://docs.lumx.io/llms.txt
Use this file to discover all available pages before exploring further.
What nesting looks like
Nesting is when an onboarded customer uses their Lumx account as a pass-through for undisclosed third parties. Common signals:- Funds in the account economically belong to someone other than the onboarded customer.
- Invoices, contracts, or payment instructions name an entity different from the account holder.
- A single customer collects payments for, or pays expenses of, multiple underlying businesses.
- The customer acts as an intermediary, routing money between two third parties, without written approval from Lumx.
- Virtual accounts or sub-balances are used to track funds belonging to other parties.
A simple test
Ask one question before any transaction: whose money is it, and whose business does it pay for? If the answer to both is the onboarded customer, the transaction fits within Lumx’s visibility model. If either side names an entity Lumx hasn’t onboarded, it’s nesting.Illustrative examples
| Scenario | Allowed | Not allowed |
|---|---|---|
| Receiving payments | Customer collects revenue for goods or services they actually provide. | Customer receives funds owed to a different, non-onboarded entity. |
| Paying suppliers or expenses | Customer pays its own vendors, employees, or operating costs. | Customer pays vendors or employees of another entity not onboarded with Lumx. |
| Treasury movements | Customer moves its own funds between its own accounts or approved external wallets. | Customer routes another party’s treasury activity through their account. |
| Virtual accounts | Used for the customer’s own commercial activity. | Used to pool or commingle multiple third parties’ funds. |
| Marketplace flows | Each seller onboarded as a Lumx customer; platform takes a partner fee. | Buyer funds pooled in one account and distributed to non-onboarded sellers. |
| Payroll | Each employer holds their own Lumx account and pays from it. | A payroll provider uses its own account to pay employees of multiple, non-onboarded employers. |
Why it’s prohibited
Nested payments break the visibility model that compliance, sanctions screening, and transaction monitoring depend on:- KYC/KYB integrity. Lumx can’t run due diligence on parties it can’t see.
- Sanctions screening. Hidden counterparties evade screening against restricted lists.
- Transaction monitoring. Pooled or masked flows defeat pattern detection.
- Regulatory exposure. Acting as an undisclosed intermediary can amount to operating as an unlicensed payment institution.
- Operational risk. Commingled funds create reconciliation gaps and dispute exposure.
Approved structures by use case
Some business models legitimately involve money flowing between multiple parties. These are allowed only when every party in the chain is visible to Lumx. The tables below break down what each model looks like in practice.Marketplaces and platforms
| Area | Acceptable | Nested (avoid) |
|---|---|---|
| Onboarding | Each seller is onboarded as its own Lumx customer. | Sellers transact through the platform’s account without their own Lumx onboarding. |
| Funds flow | Buyer payments are split between seller and platform via Lumx; sellers receive funds in their own account. | All buyer funds land in the platform’s account; the platform distributes to sellers off-platform. |
| Platform fees | Collected via the partner fee mechanism. | Skimmed from a commingled pool before forwarding to sellers. |
Payroll providers
| Area | Acceptable | Nested (avoid) |
|---|---|---|
| Onboarding | The employer has its own Lumx account and is approved by Lumx. | A payroll provider uses its own Lumx account to pay employees of non-onboarded employers. |
| Accounts | The payout account belongs to the approved employer. | The provider pools multiple employers’ payroll funds in its own account. |
| Payments | Each payout originates from the employer’s account with documentation matching that employer. | The provider sends payouts in its own name on behalf of an employer Lumx hasn’t seen. |
Investment vehicles and SPVs
| Area | Acceptable | Nested (avoid) |
|---|---|---|
| Onboarding | The fund or SPV is onboarded as its own customer, separate from the manager. | Only the fund manager is onboarded; investor money for multiple vehicles flows through the manager’s account. |
| Investor flow | Subscriptions and redemptions go through the fund’s own account. | Subscription funds for multiple vehicles are pooled in the manager’s account. |
| Documentation | Subscription agreements and capital calls name the fund as counterparty. | Documents name the fund but funds clear through an unrelated entity. |
Payment processors and PSPs
| Area | Acceptable | Nested (avoid) |
|---|---|---|
| Underlying customer visibility | Each legal entity whose funds are moved is separately onboarded with Lumx, or expressly approved under a written structure. | The processor uses one Lumx relationship to move funds for many merchants Lumx hasn’t onboarded. |
| Use of the platform | The processor operates only within the bounds of an approved model and documented control framework. | The processor effectively provides downstream access to Lumx without prior written approval. |
| Documentation | Supporting records identify the same entity that owns the account and is sending or receiving funds. | Documentation names one party while payments are initiated from another, unrelated account. |
When written approval may be required
Some business models involve layered payment activity, agency, merchant acquisition, payout programs, or other arrangements that require a separate written agreement, enhanced due diligence, and additional oversight. In those cases, a structure that would otherwise look nested may be permitted only if Lumx has expressly approved it in writing and the customer operates strictly within that approved model. Operational convenience, internal sub-ledgers, or contractual arrangements with your own customers aren’t enough. Visibility to Lumx, direct onboarding of the relevant party, and written approval where applicable remain the requirements. For pre-approval, email compliance@lumx.io.Compliance checklist
Before initiating a transaction, confirm:- The funds belong to the onboarded customer.
- Invoices, contracts, or payment references name that same customer.
- The counterparty (sender or recipient) is either the customer itself or a disclosed, approved third party (e.g. a registered destination holder).
- No undisclosed business is collecting or distributing funds through the account.
Consequences of non-compliance
Transactions that don’t meet the visibility requirement may be delayed, rejected, or reversed. Repeated or serious violations can result in account suspension or termination, and Lumx may report the activity to the relevant authorities.Related resources
Prohibited business activities
Industries and activities Lumx doesn’t support, including unlicensed money services.
Partner Fees
How marketplaces and platforms collect revenue without nesting.
Marketplaces guide
Reference flow for onboarding every seller as a customer.
Payroll guide
Reference flow for employer payouts without pooling client funds.