Nested Payments

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.

​

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

​

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

​

Payroll providers

​

Investment vehicles and SPVs

​

Payment processors and PSPs

​

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:

1. The funds belong to the onboarded customer.
2. Invoices, contracts, or payment references name that same customer.
3. The counterparty (sender or recipient) is either the customer itself or a disclosed, approved third party (e.g. a registered destination holder).
4. 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