Nesting

Overview

At Rail, we prohibit “nesting” — when an account is used to move money on behalf of a person or entity who is not onboarded to Rail. Nesting hides the true sender or recipient, prevents required compliance checks, and creates serious legal and regulatory risks. Because of this, nesting is not permitted under your Platform Agreement unless approved in writing by Rail. This guide explains what nesting is (and is not), why it matters, and how to avoid it so your payments stay seamless and compliant.

Contractual Obligations:

All Rail clients sign a Platform Agreement that outlines our expectations and guidelines for client behavior. The prohibition of Nested Payments is called out in section 2.21 of that agreement.

Contractual language is included below, but in summary: You have agreed to only use Rail services for yourself and your direct, onboarded customers. You can’t move money for others, pool funds, or extend access to other financial institutions — unless you have Rail’s explicit written approval.

2.21. Nested Payments Prohibition. Subscriber covenants and agrees that neither it nor any End User will not facilitate Nested Payments in connection with any services provided by Layer2 Holdings. “Nested Payments” means (a) a payment or payment instruction provided by Subscriber or End User (or any party acting on behalf of any such party) (i) that relates to more than one underlying transaction or party; (ii) where, in the case of receipt of funds, the ultimate beneficiary of the transaction is not the Subscriber or End User; or (iii) where, in the case of sending of funds, the funds do not belong exclusively to the Subscriber or End User; (b) any event in which Subscriber or End User provides access to Layer2 Holdings’ services hereunder or under a Customer Agreement to another financial institution (including non-bank financial institution, whether licensed or unlicensed). Subscriber shall ensure that any transaction for which Layer2 Holdings settles or processes under this Agreement or in connection with an End User transaction must be conducted for the benefit of and by only Subscriber or End Users, unless otherwise approved in writing by Layer2 Holdings. Subscriber may not offer any Layer2 Holdings’ services to, or use Layer2 Holdings services in connection with providing its services to, any financial institution (including non-bank financial institution, whether licensed or unlicensed), except as approved in writing by Layer2 Holdings.

Nesting at Rail

What is Nesting?

Nesting refers to the use of a financial service to send or receive payments on behalf of another party who isn’t onboarded to that financial service. In other words: you’re moving money that isn’t yours, or you're processing payments where the true sender or receiver is hidden.

Example A - Sending:

Company A SENDS money FROM its own Rail account on behalf of Company B.
Company B was never onboarded or screened by Rail.
Rail can’t verify who Company B is — which creates serious risk for all companies involved.

Example B - Receiving:

Company A RECEIVES money TO its own Rail account on behalf of Company B.
Company B was never onboarded or screened by Rail.
Rail can’t verify who Company B is — which creates serious risk for all companies involved.

Why is Nesting Not Allowed?

Nesting creates legal and regulatory risks for you, Rail, and our banking partners.

Nesting hides the true origin, destination, or intent of fund movements. Nesting prevents Rail from running necessary KYC / AML checks on involved entities. Nesting can lead to accidental payments to sanctioned or high-risk entities, with severe repercussions.

What is (and what is not) Nesting?

A quick test is to ask yourself “am I moving money that doesn’t belong to me or my company?” If the answer is “yes”, then it’s nesting. Examples below:

Nesting ❌	Not Nesting ✅
A fintech receives deposits from their customers into the fintech’s own account, where the owner of the funds is still the customer, not the fintech. Ownership of funds has NOT changed ownership from the end customer.	A fintech receives a deposit from their customer into the fintech’s own account, where the deposit represents a payment for services rendered to the customers by the fintech. Ownership of funds has changed from customer to fintech.
A fintech withdraws funds to a supplier from the fintech’s own account to make a payment on behalf of their customer.	A fintech withdraws funds to a supplier from the fintech’s own account to make a payment that is related to their own business, not any of their customers.

Best Practices

Best Practice	Description
Onboard the correct entity	The true owner of funds must be onboarded and registered with Rail.
Upload documents before sending	Upload supporting documentation to payment before sending.
Match documents to payments	f the supporting documentation says the invoice / payment is between Entity X and Counterparty B, the withdrawal MUST be from an account owned by Entity X. If the supporting documentation does not match payment request it’s likely the payment will be rejected.
Explore Rail's Affiliate Model	Rail's affiliate model enables you to onboard your customer's end customer in a separate instance to the rest of your existing customers.

Un-nested Payments by Use Case

Payment Collections

Investment Vehicles - Funds, SPVs, etc.

A fund manager / admin collecting investments from the investors of a fund they manage.

	Un-nested Approach ✅	Nested Approach ❌
Onboarding	The fund (or investment vehicle) itself must be onboarded as a corporate customer. The Ultimate Beneficial Owner (UBO) recorded should be the UBO(s) of the fund itself (i.e. the individuals who ultimately own or control the fund’s equity or interests). If the fund has no identifiable UBO, then designate the fund manager as the UBO. If the UBO is another corporation, trace ownership through that entity until the natural person(s) with ultimate ownership or control are identified (e.g. in a multi-layered or complex structure).	The fund (or investment vehicle) is NOT onboarded. The fund manager / admin is the only entity KYC'd by Rail.
Accounts	Each investment vehicle onboarded gets their own set of accounts associated with their customer.	They CANNOT set up different accounts under the fund manager customer, each account representing a different fund or investment. They CANNOT pool all of the investment vehicles they work with in a single account.
Payments	Payments are collected from investors into accounts belonging to the fund / investment vehicle itself. Not to that of the fund manager.	The fund manager / admin CANNOT collect investments into an account under the fund manager’s name on behalf of the fund.

Payments / Payouts

Payroll Providers

A payroll processor processing payments on behalf of employers to their employees.

	Un-nested Approach ✅	Nested Approach ❌
Onboarding	The employer looking to make payments to their employees must be onboarded itself as a corporate customer.	The employer wishing to pay their employees is NOT onboarded. The payroll provider is the only entity KYC'd by Rail.
Accounts	Each employer onboarded gets their own set of accounts associated with their customer.	The payroll processor CANNOT pool funds belonging to different employers into accounts owned by the payroll processor. They CANNOT pool all of the employers they work with in a single account. They CANNOT set up different accounts under the payroll processor customer, each account representing an individual employer’s funds.
Payments	Payments are made from accounts belonging to the relevant employer, not that of the payroll provider.	The payroll provider CANNOT make payments from an account in their name on behalf of the employer.

Payment Processors

A payment processor processes payments on behalf of their customers - paying suppliers, contractors, etc.

	Un-nested Approach ✅	Nested Approach ❌
Onboarding	Each entity for whom the payment processor is making payments must be onboarded.	The entity wishing to make the payments is NOT onboarded. The payment processor is the only entity KYC'd by Rail.
Accounts	Each entity onboarded gets their own set of accounts associated with their customer.	The payment processor CANNOT pool funds belonging to different entities into accounts owned by the payment processor. They CANNOT pool all of the entities they work with in a single account. They CANNOT set up different accounts under the payment processor, each account representing an individual entity’s funds.
Payments	Payments are made from accounts belonging to the relevant entity, not that of the payment processor.	The payment processor CANNOT make payments from an account in their name on behalf of their customers.