Who Will Bank a Payments or Money Services Business?
For a payments company, a bank account is not a commodity. It is infrastructure, permission, settlement access, and a continuing vote of confidence. The account must survive not only onboarding but also the moment the business begins receiving real customer funds, moving them across borders, converting currencies, interacting with sponsors or exchanges, and producing activity that looks nothing like an ordinary software company.
The answer to “who will bank our business?” begins with a distinction that is routinely ignored: which banking function do you actually need? A company may require an operating account, a customer-funds account, a safeguarding or FBO structure, collection accounts, virtual accounts, settlement rails, prefunding accounts, reserve accounts, FX, card settlement, or access to instant payments. One bank may support only some of these. Another may support the product but reject the ownership, countries, or transaction profile.
The right banking partner is not simply “MSB-friendly.” It is a bank whose charter, risk appetite, compliance capabilities, correspondent network, technology, and commercial model align with the exact flow.
Banking is a Stack of Functions
An operating account pays salaries, vendors, taxes, and ordinary corporate expenses. It should not be assumed to support customer money.
A customer-funds account receives or holds funds that belong economically or legally to users. Depending on the jurisdiction and model, it may be structured as a safeguarding account, trust account, custodial account, FBO account, pooled account with sub-ledgers, or another protected arrangement.
A settlement account connects the business to payment rails and counterparties. It may send wires, ACH, instant payments, local transfers, card settlements, or payouts.
A collection structure receives incoming funds. It may use named or virtual accounts, unique references, open-banking initiation, card acquiring, direct debit, or bank transfer.
A treasury or liquidity account supports FX, stablecoin conversion, prefunding, reserves, or intercompany movements. These flows often receive heightened scrutiny because the bank must understand the counterparties and economic purpose.
A resilient payments company may need several institutions because one bank rarely performs every role well.
How Banks Actually Decide
Banks do not accept or reject a business based solely on whether it holds a license. They make a risk- adjusted decision. The relevant question is not “is this legal?” but “can the bank understand, monitor, control, price, and defend this relationship?”
Regulatory guidance in the United States repeatedly emphasizes a risk-based approach rather than categorical exclusion. That principle does not compel a bank to accept any particular company. It means the bank is expected to assess the individual customer and manage the risk. For the applicant, the implication is clear: the burden is to make the risk legible.
A bank’s assessment usually covers the following dimensions.
Ownership and Management
The bank will identify ultimate beneficial owners, controllers, directors, and key executives. It will assess experience, reputation, financial history, source of wealth, litigation, adverse media, prior regulatory issues, and the credibility of the management team.
Complex ownership, unexplained nominees, rapid changes in control, or investors from high-risk jurisdictions can delay or end an application. A strong application explains the ownership chain before the bank has to reconstruct it.
Regulatory Status
The bank will verify licenses, registrations, exemptions, sponsor relationships, agent appointments, and the scope of authority. It will ask whether the company is active, whether applications are pending, whether a change of control has been approved, and whether the proposed activities fit the permissions.
A federal registration that is presented as a national operating license damages credibility. So does a Montana exemption described as a transferable money-transmitter license. Banks notice when regulatory descriptions are inflated.
Customers and Use Cases
The bank will want to know who sends money, who receives it, why the transaction occurs, and how the company prevents misuse. “B2B payments” is not specific enough. A platform paying verified software suppliers is different from a marketplace settling unknown merchants, an OTC crypto intermediary, a gaming operator, or a remittance program serving cash-heavy corridors.
The application should define customer types, industries, countries, expected transaction purposes, prohibited categories, onboarding standards, and ongoing monitoring.
Geography and Counterparties
Banks evaluate customer locations, beneficiary countries, correspondent banks, payout partners, exchanges, custodians, agents, and other intermediaries. Sanctions exposure, high-risk jurisdictions, weak local regulation, cash payout, nested relationships, and opaque counterparties increase concern.
A corridor is not just two country names. It is a chain of institutions and obligations. The bank needs to know each meaningful participant.
Flow, Volume, and Velocity
Projected volume must be credible. Banks compare expected monthly value, transaction count, ticket size, funding methods, settlement timing, return rates, and peak days with the company’s capital, staff, and controls.
A startup that projects enormous volume in the first month without signed customers or operational history looks speculative. A company that understates expected activity and then grows abruptly creates a monitoring problem and may trigger account restrictions.
Compliance and Control Environment
The bank will review AML, sanctions, fraud, cybersecurity, complaints, transaction monitoring, audits, training, risk assessments, and governance. It may ask for sample alerts, escalation procedures, independent testing, vendor contracts, and evidence that management receives reporting.
The bank is also assessing whether the company can answer questions quickly after onboarding. An applicant that takes weeks to explain a transaction is expensive to supervise.
Commercial Value
Risk is only half of the equation. The relationship must also make economic sense. Banks consider balances, payment volume, fee revenue, operational workload, integration cost, reserve requirements, and the resources needed for ongoing review. A high-risk, low-revenue account is difficult to justify.
The Banking Requirements Matrix
Banking need | Typical structure | What the bank will test |
Corporate expenses | Operating account | Ownership, source of funds, ordinary business purpose |
Customer collections | Pooled, named, or virtual accounts | Customer ownership, reconciliation, payment purpose |
Safeguarding/customer funds | Segregated, trust, FBO, or safeguarded account | Legal protection, daily reconciliation, access controls |
Domestic payments | ACH, wire, instant-payment access | Fraud, returns, authorization, transaction monitoring |
Cross-border settlement | Correspondent or partner network | Countries, counterparties, sanctions, message quality |
FX and treasury | Bank FX, broker, or liquidity accounts | Economic purpose, rates, counterparties, market and settlement risk |
Stablecoin or crypto conversion | Bank plus exchange, OTC, or custodian | Source of funds, wallet controls, asset and counterparty risk |
Card program or acquiring | Settlement and reserve accounts | Merchant/customer profile, chargebacks, fraud, network compliance |
Why Applications Fail
The most common failure is approaching the wrong institution. A bank may have no appetite for customer- funds accounts, no correspondent coverage for the corridor, no ability to support virtual accounts, or a policy against crypto-related flows. No amount of presentation can convert a structural mismatch into approval.
The second failure is an incomplete or inconsistent story. The business plan says consumer remittance. The website says global crypto payments. The flow diagram shows corporate clients. The financial model assumes card funding. The compliance manual discusses bank transfers only. Each inconsistency creates another diligence question.
The third failure is treating the bank as a passive utility. Banks must understand third-party relationships, customer funds, transaction risk, and operational dependencies. They will ask who performs onboarding, who controls the ledger, how funds are reconciled, what happens on termination, and how the bank can access records.
The fourth failure is hiding the difficult part. Some applicants describe only the first leg of the transaction and omit the exchange, OTC desk, nested PSP, cash payout, high-risk beneficiary, or stablecoin conversion. The omission may secure an initial conversation, but it usually destroys trust later.
The fifth failure is weak evidence. A polished policy manual cannot compensate for no compliance owner, no audit plan, no transaction-monitoring configuration, no signed customer pipeline, and no realistic volume model.
Build a Bank-Ready Package
A serious banking package should allow a relationship manager and compliance team to understand the business without repeated reconstruction. It should include:
A concise executive summary;
Corporate structure and ownership chart;
Management biographies;
Regulatory status and supporting evidence;
Detailed product description;
Customer, geography, and use-case matrix;
Visual flow of funds with account titles and counterparties;
Historical or projected volume by corridor and rail;
Compliance program summary and risk assessment;
Policies, audit reports, and licenses where requested;
Technology, security, ledger, and reconciliation overview;
Financial statements and capitalization;
Key contracts or sponsor confirmations; and
A clear statement of the exact account and rail requirements.
The package should be consistent with the website, pitch deck, customer terms, provider contracts, and actual system. It should also state what the company does not support. Boundaries make a risk program credible.
The Role of the Sponsor Bank
In embedded-finance and sponsor-led models, the bank is not merely providing an account. It may enable customer accounts, payment rails, cards, ledger integration, compliance oversight, or regulated products delivered through the fintech. That relationship is a third-party arrangement subject to extensive risk management.
The bank will evaluate the fintech’s governance, financial condition, technology, consumer compliance, fraud controls, vendors, complaint handling, data practices, business continuity, and exit planning. The commercial contract may allocate responsibilities, but the bank remains concerned with how the program performs in reality.
A sponsor-bank program should therefore be treated as a regulated operating partnership. The fintech needs evidence, reporting, auditability, and the ability to adapt when the bank changes risk limits or regulatory expectations.
Crypto and Stablecoin Banking
Crypto-related businesses face an additional layer because the bank must understand both fiat and digital- asset flows. It will want to know which assets and chains are used, who controls wallets, which exchanges or OTC desks participate, how blockchain addresses are screened, how source of funds is established, and how the company prevents sanctioned or illicit activity.
Stablecoins can improve settlement speed and reach, but they do not make the banking layer disappear. Fiat must enter and leave somewhere. Reserves, issuers, custodians, exchanges, and counterparties introduce their own risks. A business that cannot explain the full fiat-to-token-to-fiat chain is not bank-ready.
Design for Resilience, not a Single Approval
A bank account is a revocable relationship. The business should assume that risk appetite, pricing, correspondent access, ownership, regulation, or strategy can change.
Resilience may include:
Separating operating funds from customer funds;
Using more than one bank where practical;
Maintaining alternative payout or collection providers
Keeping clean, portable compliance and transaction records;
Avoiding a ledger that depends entirely on one bank’s interface;
Negotiating wind-down and data-access provisions;
Monitoring concentration limits and settlement exposure; and
Maintaining enough liquidity to survive delays or account transition.
The objective is not to hide activity across multiple banks. It is to avoid a single point of failure while ensuring every institution understands its role.
Who will Bank the Business?
The answer is likely to be a specific type of institution for a specific function, not one universal “fintech bank.” A community or regional bank may support domestic payments but not complex cross-border settlement. A major bank may have the capabilities but require substantial scale and mature controls. A specialist institution may understand MSBs but impose high fees, reserves, or narrow corridors. An EMI or safeguarding bank may solve customer-funds protection but not U.S. Payment rails. A sponsor platform may package several functions but create concentration risk.
The selection process should begin with a requirements matrix and provider fit, then move to a complete, transparent application. The best bank is the one that understands the business, supports the required flow, prices the risk rationally, and can remain comfortable as the company grows.
How Faisal Khan LLC can Help
Faisal Khan LLC helps payment businesses define the banking structure they need, prepare the business for diligence, and identify the types of institutions and partners likely to support the model. The work covers operating accounts, customer-funds structures, safeguarding, FBO accounts, settlement rails, cross-border flows, FX, stablecoin conversion, and sponsor-bank arrangements.
The first step is not an introduction. It is making the model bankable: a clear flow of funds, verified regulatory status, credible compliance controls, realistic volumes, transparent counterparties, and a precise statement of banking requirements. That preparation determines whether a conversation becomes an account.
Assess Your Banking Structure
Start with the business model, flow of funds, jurisdictions, counterparties, and intended transaction. The assessment is designed to identify the viable structure, the missing dependencies, and the route that can withstand bank, provider, regulator, and operational scrutiny.
Selected Authoritative References
These references support the current regulatory and supervisory context. They are not a substitute for jurisdiction-specific legal advice.