A Practical Guide to the Commercial, Regulatory, Compliance, Banking, Technical and Operational Process

Introduction

Becoming an authorized delegate of a licensed U.S. money transmitter is fundamentally different from simply buying access to a payment API.

An API relationship gives a company technology.

An authorized-delegate relationship gives the company an agency relationship with a licensed money transmitter and, where permitted under applicable state law and properly appointed, the ability to conduct money-transmission activity on behalf of that principal.

That distinction is critical.

The authorized delegate does not acquire the principal's licenses. It does not become the license holder. Rather, it operates as an agent of the licensed principal, within a defined contractual, regulatory, compliance and operational framework.

The practical result can be extremely powerful. Instead of independently obtaining a money-transmitter license in every state where one may otherwise be required, a company may be able to launch under the licensing umbrella of an existing multi-state licensed money transmitter.

Download this Primer as a PDF

But the arrangement comes with significant obligations.

The principal is placing its licenses, regulatory standing, banking relationships and reputation behind the authorized delegate. It therefore needs considerable control over how customers are onboarded, transactions are processed, funds move, disclosures are presented, compliance decisions are made, data is recorded and suspicious activity is escalated.

The correct way to think about an authorized-delegate arrangement is therefore:

You are not renting a license. You are becoming part of the regulated operating framework of the license holder.

That principle explains almost everything that follows.

1. The Basic Structure

A typical arrangement involves several parties.

The Principal License Holder

This is the regulated U.S. money transmitter that holds the relevant state money-transmitter licenses.

It normally controls the regulatory framework, compliance program, transaction-processing infrastructure and the authorized-delegate program.

The Authorized Delegate

This is the company appointed to provide money-transmission services as an agent of the principal.

The authorized delegate may operate its own brand, website, mobile application, customer-acquisition strategy and support operation, but it must operate within the boundaries imposed by the principal.

Banking and Payment Partners

These may include banks, ACH processors, account-verification providers, card processors or other regulated financial institutions used by the principal.

The authorized delegate generally does not independently connect its money-transmission flow directly to a bank outside the approved architecture.

Foreign Payout Partners or Regulated Affiliates

For cross-border remittance, funds eventually need to be delivered in another country.

The foreign side may therefore involve:

• a regulated affiliate;

• a licensed payment institution;

• a bank;

• a payout network;

• a regulated remittance company; or

• another approved correspondent.

One particularly efficient model is for the principal to establish a relationship with one appropriately regulated foreign affiliate or aggregator, which can subsequently manage multiple destination-market payout relationships.

This prevents the U.S. principal from necessarily having to negotiate a new correspondent agreement every time the authorized delegate wishes to open another corridor.

Any such structure remains subject to the principal's approval and the applicable licensing requirements in each jurisdiction.

2. Authorized Delegate Versus API Access

This distinction deserves special emphasis.

A pure API provider may effectively tell a fintech:

"Here are our payment APIs. You are responsible for determining whether you need licenses."

That does not solve the licensing problem.

If the fintech accepts and transmits customer funds in circumstances constituting regulated money transmission, the fintech may still need its own licenses.

An authorized-delegate arrangement is different.

The company is formally appointed to act on behalf of the licensed money transmitter within the permitted program.

This can allow the delegate to participate in the regulated movement of customer funds under the principal's framework rather than merely consuming payment infrastructure.

Therefore:

API access does not automatically provide regulatory coverage.

Authorized-delegate status is a regulatory and contractual relationship, not merely a technical integration.

The APIs are simply the technological mechanism through which the authorized-delegate program is implemented.

3. Start Simple: Simplex Before Complex

One of the most useful strategies when entering the U.S. market is to resist the temptation to launch everything simultaneously.

Do not begin with:

• numerous countries;

• multiple funding methods;

• multiple payout structures;

• P2P and B2B simultaneously;

• cards plus ACH plus wires;

• multiple corporate entities;

• several compliance workflows; and

• numerous exception cases.

Start with the simplest viable product.

For example:

United States → Destination Market A

using:

one customer type + one funding method + one payout model + one principal + one regulated foreign payout structure.

Get that functioning properly.

Then expand.

The objective during the first phase is not to demonstrate how sophisticated the company can be.

The objective is to demonstrate that the company can operate safely, compliantly and reliably under the principal's program.

Once that operating history exists, additional corridors, payment methods and products become significantly easier to discuss.

4. Decide Which Corporate Entity Will Become the Delegate

Before onboarding begins, the corporate structure needs to be clear.

A group may have:

• a U.S. operating company;

• a foreign licensed company;

• technology subsidiaries;

• holding companies; and

• local payout entities.

The principal will want to know exactly which company is entering into the authorized-delegate agreement.

Do not unnecessarily create a complicated triangular structure.

For example, if Entity A signs the authorized-delegate agreement, Entity B owns the application and Entity C receives the settlement funds, the principal must understand why each entity exists and why funds or data are moving between them.

Every additional entity creates additional:

• KYB;

• ownership verification;

• contracts;

• compliance analysis;

• accounting;

• banking scrutiny;

• data-flow analysis; and

• regulatory questions.

The preferred principle should be:

Use the simplest legally defensible corporate structure capable of accomplishing the business objective.

Complexity can always be introduced later.

5. The Foreign Licensed Affiliate or Aggregator Model

For an international-remittance program, an authorized delegate may already operate a licensed entity outside the United States.

That can be strategically valuable.

Rather than requiring the U.S. principal to establish a separate commercial relationship with every payout company in every destination country, the structure may potentially be:

U.S. Principal → Regulated Foreign Affiliate → Approved Local Payout Partners

The foreign regulated affiliate essentially becomes the international payout aggregator.

The principal settles according to the agreed structure with that regulated affiliate, and the affiliate manages onward settlement and payout.

The foreign affiliate must then provide appropriate transaction and proof-of-delivery information back through the chain.

This can substantially simplify corridor expansion.

If Destination Market B is added later, it may not require rebuilding the entire U.S. regulatory architecture. Instead, the delegate presents the new corridor to the principal for review and approval and demonstrates that the destination-side licensing, banking, sanctions, AML, liquidity and payout arrangements are satisfactory.

The principal may nevertheless require information or agreements concerning underlying payout partners.

6. Accounts Must Match the Regulatory Structure

Money should not simply be settled to whatever corporate account is most convenient.

If the principal is contracting with a regulated entity, it may require settlement into an account belonging to that entity or another specifically approved account within the contractual flow.

For example, it is generally problematic to say:

"We contracted with regulated Entity A, but please settle the customer funds into unrelated sister company Entity B."

That breaks the clean chain of accountability.

A well-designed structure allows every participant to demonstrate:

1. who accepted the funds;

2. on whose behalf the funds were accepted;

3. where those funds were held;

4. who controlled the funds;

5. who instructed the payout;

6. who ultimately received the settlement; and

7. under what license or regulatory authority each step occurred.

Named or properly designated settlement accounts are therefore a significant component of the architecture.

7. Initial Introduction and NDA

Once an appropriate principal is identified, the normal commercial process begins.

The first stage is usually an introduction.

The introduction normally identifies:

• the prospective authorized delegate;

• its ownership;

• its business;

• its regulatory history;

• its existing licenses, if any;

• its intended U.S. product;

• anticipated volume;

• intended funding methods;

• corridors;

• customer types; and

• the reason the principal may wish to consider the opportunity.

An introductory call normally follows.

If there is mutual interest, an NDA is generally executed relatively early.

The NDA matters because the parties will soon exchange sensitive information covering:

• pricing;

• compliance;

• banking relationships;

• APIs;

• underwriting;

• customer information;

• financial statements;

• fraud controls;

• corporate ownership;

• technical architecture; and

• proprietary operating procedures.

The NDA frequently becomes the gate that allows the substantive onboarding process to begin.

8. Due Diligence Begins

Once the parties decide to proceed, the principal conducts KYB and enhanced due diligence on the prospective delegate.

Typical requirements may include:

Corporate Documents

• certificate of incorporation or formation;

• articles or operating agreement;

• organizational chart;

• registered address;

• business addresses;

• tax identification information;

• ownership register;

• corporate resolutions;

• licenses;

• regulatory registrations;

• banking information; and

• information concerning affiliates.

UBO and Management Information

The principal will identify and screen ultimate beneficial owners, directors and key executives.

Depending on its underwriting program, this may include:

• identification;

• address verification;

• biographies;

• resumes;

• source-of-wealth information;

• background checks;

• regulatory-history declarations; and

• consent forms.

Compliance Information

The applicant may be asked for:

• AML policy;

• sanctions policy;

• customer-risk methodology;

• transaction-monitoring framework;

• fraud controls;

• suspicious-activity procedures;

• compliance organizational structure;

• compliance officer details;

• training records;

• independent review or audit reports;

• complaint procedures; and

• regulatory examination history.

Standard Industry Questionnaires

A principal may also request standardized AML or correspondent-banking questionnaires.

Financial Information

Financial statements may be required so the principal can understand whether the delegate is financially capable of operating the program.

This may include audited accounts, management accounts, bank statements or capitalization information depending upon the applicant.

The principal is underwriting a business that could create financial, fraud, compliance and regulatory exposure. Financial review is therefore not merely a formality.

9. The Mini Business Plan

A concise business plan is usually sufficient.

There is rarely a need to submit a hundred-page document.

A practical plan might be approximately several pages and explain:

• the business;

• ownership;

• management;

• existing operating history;

• current regulated activities;

• target U.S. customers;

• initial corridor;

• customer-acquisition strategy;

• funding methods;

• payout architecture;

• expected transaction sizes;

• compliance strategy;

• technology;

• projected volumes; and

• expansion plan.

The document should be conservative and credible.

Do not attempt to impress the principal by claiming enormous immediate transaction volumes.

An experienced principal understands that a new U.S. program requires ramp-up.

A stronger proposition is:

"We understand this customer population. We already operate in adjacent markets. We understand regulated payments. We have demonstrated customer-acquisition capability. We expect a structured ramp-up over several months."

That story is more credible than claiming that tens of millions of dollars will appear immediately after launch.

10. Financial Projections

Prepare at least three scenarios:

Conservative Case

Slow customer adoption and modest transaction volumes.

Base Case

The company's realistic operating expectation.

Upside Case

A successful scenario assuming marketing and corridor expansion perform well.

The projections should preferably contain:

• monthly customers;

• monthly transactions;

• average transaction value;

• total payment volume;

• revenue;

• principal fees;

• payment-processing costs;

• compliance costs;

• fraud assumptions;

• operating expenses; and

• gross contribution.

The objective is not financial theater.

The objective is to demonstrate that management understands how a U.S. remittance operation behaves economically.

11. The Principal's Compliance Manual Becomes the Operating Rulebook

One of the most important documents in the entire relationship is the principal's authorized-delegate compliance manual or program manual.

It may be relatively short or considerably more detailed.

The precise length is irrelevant.

Its importance is enormous.

The document normally describes how the delegate must operate under the principal's licenses.

It may establish requirements relating to:

• customer onboarding;

• identity verification;

• customer-risk classification;

• sanctions screening;

• transaction limits;

• velocity limits;

• transaction monitoring;

• escalation;

• suspicious activity;

• recordkeeping;

• receipts;

• disclosures;

• complaints;

• refunds;

• error resolution;

• marketing;

• use of the principal's name;

• employee training;

• cybersecurity;

• reporting;

• state-specific requirements;

• regulator notices;

• audits; and

• examinations.

For practical purposes, this manual becomes the delegate's U.S. operating rulebook.

If the manual contains something that conflicts materially with the proposed business model, that problem should be identified before significant technical development takes place.

12. U.S. Requirements Are Not Uniform

A common mistake made by companies entering the United States is assuming that "U.S. regulation" represents one homogeneous rulebook.

It does not.

There are federal requirements and state requirements.

Different states can impose different rules relating to areas such as:

• disclosures;

• receipts;

• customer notices;

• permissible activities;

• agent appointments;

• record retention;

• examinations;

• net worth;

• permissible investments;

• reporting;

• complaints;

• branch or location reporting; and

• surety bonding.

The delegate should therefore not attempt to independently invent its own receipt or compliance flow.

The principal should provide the applicable requirements, and the delegate's application and operating procedures should implement them.

13. Federal Remittance Disclosures and Cancellation Rights

Cross-border consumer remittances can also fall under the CFPB's Regulation E Remittance Transfer Rule.

Among other things, qualifying transfers can trigger requirements concerning:

• prepayment disclosures;

• receipts;

• exchange rates;

• transfer fees;

• certain taxes;

• amount expected to be received;

• expected availability;

• cancellation rights;

• error resolution; and

• complaint information.

The federal rule generally provides a sender with a 30-minute cancellation period after payment, subject to specified conditions. Importantly, the cancellation right does not continue if the funds have already been picked up by the recipient or deposited into the recipient's account. (Consumer Financial Protection Bureau)

The implementation should therefore be driven by the principal's compliance requirements rather than by informal assumptions about what a remittance receipt should contain.

14. FinCEN: An Important Distinction

FinCEN registration is federal and is separate from state money-transmitter licensing.

A person that is an MSB solely because it acts as an agent of another MSB is generally not required to file its own separate MSB registration with FinCEN. The principal, however, has agent-list obligations, and an entity conducting MSB activity independently of the agency relationship may have its own registration obligations. (FinCEN.gov)

Therefore, it is inaccurate to think of the arrangement as the delegate simply "getting a FinCEN license."

FinCEN registration is not a money-transmitter license.

Likewise, becoming an authorized delegate does not automatically mean that every activity conducted by that company outside the agency program is covered by the principal.

The scope of the agency relationship matters.

15. The Authorized Delegate Still Has Compliance Responsibility

Another critical point:

The principal's licenses do not eliminate the authorized delegate's compliance responsibility.

The principal will generally control much of the compliance infrastructure and supervise the delegate.

But FinCEN guidance makes clear that MSB principals and their agents can each have BSA/AML responsibilities, and contractual allocation of tasks does not automatically eliminate either party's regulatory liability. (FinCEN.gov)

At a minimum, the authorized delegate must understand and implement the obligations assigned to it under the program.

It cannot say:

"Compliance belongs to the principal, therefore anything suspicious is the principal's problem."

That is not how the relationship works.

The delegate is often directly interacting with the customer.

It therefore becomes part of the first line of defense.

If customer behavior, documentation, device activity, payment activity or transaction patterns appear suspicious, the delegate must follow the prescribed escalation process.

FinCEN's guidance specifically addresses principal monitoring of MSB agents and emphasizes that both sides remain responsible for effective AML controls. (FinCEN.gov)

16. Direct Interaction With Regulators

In the normal authorized-delegate model, most formal regulatory interaction is handled by the principal license holder.

The principal generally manages the licensing framework, periodic regulatory reporting and state-level relationship.

Depending upon the state and structure, the principal may also be responsible for the applicable agent appointment, notice or reporting process.

However, the delegate must maintain records of sufficient quality to withstand:

• principal audits;

• bank audits;

• compliance reviews;

• regulatory examinations;

• law-enforcement requests; and

• independent testing.

A regulator may ultimately inspect activity relating to the delegate through an examination of the principal or, where legally applicable, directly.

The correct mindset is therefore:

The principal may manage the regulatory relationship, but the delegate must operate as though every transaction could eventually be examined.

17. Identity Verification

Identity verification is one of the areas where fintech applicants frequently expect more independence than they initially receive.

A company may already have an established KYC vendor and workflow in another country.

That does not mean the principal will allow the same process for U.S. customers.

The principal may require:

• its own identity-verification system;

• its own approved vendor;

• its own sanctions-screening process;

• its own fraud engine;

• its own risk scoring;

• or a prescribed combination of these.

This is logical.

The principal is ultimately allowing transactions to occur under its regulated program.

It therefore needs confidence in the identity-verification system protecting that program.

18. Can the Delegate Keep Its Own Customer Interface?

Possibly.

There is an important distinction between:

1. who collects the customer's information; and

2. who performs or controls the regulated verification.

A delegate may potentially retain its customer-facing mobile application and collect:

• name;

• address;

• date of birth;

• identity documents;

• photographs;

• authentication information; and

• other onboarding data.

That information can then be transmitted through the principal's approved API.

The principal's system may perform the identity checks and return the result.

Conceptually:

Customer → Delegate Application → Principal Verification API → Verification Result → Delegate Application

That can preserve the delegate's user experience while still ensuring that the principal controls the verification framework.

However, this is provider-specific.

It must be established during technical and compliance onboarding.

Do not build the final onboarding architecture until this point has been confirmed.

19. The U.S. Version of the App May Need to Be Different

A company should not assume that an application designed for another jurisdiction can simply have "United States" added to a country dropdown.

The U.S. customer journey may require different:

• disclosures;

• consent language;

• receipts;

• terms;

• privacy disclosures;

• authentication;

• transaction information;

• complaint language;

• cancellation notices;

• fee presentation;

• exchange-rate presentation; and

• state-specific information.

Therefore, even when the same application code base is retained, the U.S. customer flow should be treated as its own regulated product configuration.

20. Obtain API Documentation and Sandbox Access Early

Technical integration should begin as early as the principal permits.

Ideally, once the NDA has been signed and the relationship has progressed sufficiently, the delegate should request:

• API documentation;

• sandbox credentials;

• authentication specifications;

• webhook documentation;

• error codes;

• test data;

• KYC endpoints;

• transaction endpoints;

• account-funding endpoints;

• transaction-status endpoints;

• reconciliation files;

• reporting endpoints; and

• technical support contacts.

This allows compliance onboarding and technical development to occur in parallel.

There is little benefit in completing weeks of corporate due diligence only to discover afterward that a critical product requirement cannot be supported by the API.

The engineering team should therefore begin examining the technical architecture as early as possible.

21. Transaction Data Must Flow Through the Principal's Architecture

If the delegate is acting under the principal's program, regulated transactions cannot simply bypass the principal.

The principal must have sufficient visibility and control to supervise the activity occurring under its licenses.

Consequently, transaction events will generally pass through the principal's approved infrastructure.

Depending upon the implementation, this could include:

• authentication;

• customer verification;

• funding;

• account validation;

• transaction creation;

• compliance checks;

• transaction approval;

• payout instructions;

• transaction status;

• reconciliation;

• refunds;

• reversals; and

• logs.

The precise API architecture varies between principals.

The important principle is that the principal must maintain sufficient data and control to meet its regulatory and compliance obligations.

22. Data Residency and Data Protection Must Be Addressed Early

International fintechs frequently host infrastructure outside the United States.

A question therefore arises:

Can U.S. customer information be stored in another country?

There is no responsible universal yes/no answer.

The company needs to examine:

• the principal's information-security policy;

• bank-partner requirements;

• applicable federal requirements;

• applicable state privacy and cybersecurity requirements;

• contractual requirements;

• cross-border data-transfer rules;

• data-processing agreements;

• encryption requirements;

• retention requirements; and

• any foreign privacy regime applicable to the company's infrastructure.

Do not assume that every U.S. state requires domestic hosting.

Equally, do not assume that foreign hosting will automatically be acceptable.

Data architecture should be explicitly approved before production deployment.

23. Training and Operational Readiness

The principal normally conducts some form of authorized-delegate onboarding and training.

This may involve:

• compliance personnel;

• operations;

• customer support;

• management;

• finance;

• reconciliation staff; and

• engineering.

Training may cover:

• AML;

• sanctions;

• fraud;

• transaction review;

• escalation;

• reporting;

• customer complaints;

• disclosures;

• account funding;

• refunds;

• error resolution;

• reconciliation;

• system access; and

• incident reporting.

Access rights may then be provisioned according to role.

The first production transactions may receive enhanced monitoring while both organizations validate the program.

24. Banking and Settlement

A central question is:

Where does the customer's money actually go?

The principal or its banking structure will normally provide an approved mechanism through which customer funds are collected.

Depending upon the program, the structure may involve:

• a pooled account;

• FBO architecture;

• custodial arrangements;

• settlement accounts;

• prefunded accounts; or

• another approved structure.

The exact legal title and ownership of these accounts matter.

The delegate should not independently improvise the funds flow.

A written flow-of-funds diagram should identify every movement.

25. Funds Good and Settled Versus Immediate Payout

There are two fundamentally different approaches to payout timing.

Model A — Funds Good and Settled

The customer authorizes the funding transaction.

The system waits until the incoming funds have actually settled.

Only after settlement is the outbound payout released.

Conceptually:

Customer Funding → Settlement Confirmed → Payout Released

This materially reduces settlement risk.

However, the customer experience may be slower.

Model B — Risk-Based Immediate Payout

The customer authorizes the funding transaction.

Based on:

• identity;

• transaction history;

• account ownership;

• device information;

• fraud score;

• customer limits; and

• other risk controls,

the delegate releases the payout before final settlement of the incoming funding leg.

Conceptually:

Funding Authorization → Risk Approval → Immediate Payout → Incoming Settlement Later

The second model gives a much faster customer experience.

But somebody is taking settlement risk.

That party is usually the delegate.

26. Prefunding

The principal provides regulatory infrastructure.

It is generally not financing the delegate's remittance business.

If the delegate wants near-instant overseas payout before U.S. collection has completely settled, it generally needs liquidity available on the payout side.

This is prefunding.

The delegate may therefore maintain liquidity with:

• its foreign regulated affiliate;

• correspondent banks;

• local payout providers;

• liquidity partners; or

• approved settlement accounts.

The economic question becomes:

How much capital is required to support expected transaction velocity before incoming funds settle?

That should be modeled before launch.

At meaningful transaction volumes, liquidity management becomes a treasury function rather than merely an operational task.

27. ACH Risk

ACH is extremely useful for remittance funding, but companies entering the United States must understand that ACH transfers can generate returns, disputes and fraud exposure.

A transaction being successfully initiated does not necessarily mean the economic risk has disappeared.

A fraudster may establish a legitimate-looking history and later dramatically change behavior.

For example, a customer may consistently perform relatively small transfers and subsequently attempt a much larger transaction.

The recipient receives the money.

The original debit is later disputed or returned.

The delegate may then face:

• loss of principal;

• ACH return fees;

• dispute-management costs;

• additional reserves;

• increased monitoring;

• processor scrutiny; and

• potentially higher pricing.

This is why transaction monitoring should consider changes in behavior rather than simply asking whether the customer passed KYC.

28. Account Verification and Fraud Mitigation

Bank-account ownership and account-linking technology can materially improve the funding process.

Useful controls may include:

• confirming account ownership;

• validating account status;

• obtaining appropriate ACH authorization;

• device fingerprinting;

• IP analysis;

• behavioral monitoring;

• transaction velocity controls;

• transaction-size limits;

• step-up verification;

• customer history;

• authentication evidence; and

• risk scoring.

No tool eliminates fraud.

The objective is to reduce fraud to economically manageable levels.

A company should measure:

fraud loss / total payment volume

and:

fraud loss / transaction revenue

because seemingly small fraud percentages can destroy a low-margin remittance product.

29. Pricing: Never Evaluate Only the Headline Rate

When the principal presents its initial commercial proposal, evaluate the entire economic structure.

Possible components include:

• onboarding fee;

• monthly minimum;

• per-transaction fee;

• basis-point charge;

• KYC fee;

• account-verification fee;

• ACH fee;

• return fee;

• wire fee;

• compliance fee;

• platform fee;

• reserve requirement;

• prefunding requirement;

• settlement fee;

• state-related pass-through costs;

• support charges; and

• additional-product charges.

The first pricing proposal should normally be treated as the beginning of a commercial discussion rather than automatically accepted.

30. Negotiate the Monthly Minimum

A new delegate generally has little or no U.S. volume on day one.

A large monthly minimum immediately after contract execution may therefore create unnecessary burn.

One possible structure is a ramped minimum.

For illustration:

Month 1 → Lower minimum

Month 2 → Increased minimum

Month 3 → Increased minimum

Month 4 onward → Full agreed minimum

The exact numbers are commercial.

The concept is what matters.

The principal receives its target economics once the program has had time to launch, while the delegate avoids paying full production pricing before it has meaningful production volume.

31. Negotiate When Billing Starts

Do not negotiate only how much will be paid.

Negotiate when charging begins.

There may be a period during which:

• contracts are being completed;

• APIs are being integrated;

• compliance changes are being implemented;

• sandbox tests are underway;

• state appointments are being processed;

• production credentials have not been issued; and

• no customer can yet transact.

The agreement should make clear whether monthly fees begin:

• at signing;

• after a specified development period;

• on technical certification;

• upon production approval;

• upon first transaction; or

• on another agreed date.

This can represent a material difference in launch cost.

32. Personal Guarantees

Some principals may request personal guarantees.

Do not treat a personal guarantee as routine paperwork.

It changes the risk profile substantially because liabilities that otherwise belong to the corporate entity may potentially become obligations of founders or shareholders.

If requested, understand:

• what exactly is guaranteed;

• whether the guarantee is capped;

• what events trigger it;

• how long it survives;

• whether fraud losses are included;

• whether regulatory penalties are included;

• whether payment defaults are included; and

• whether it can be removed.

A personal guarantee should be negotiated as a substantive commercial point rather than signed automatically.

33. Surety Bond and Regulatory Cost Exposure

State money-transmitter licenses frequently involve surety bonds.

Those bonds belong to the principal's licensing framework.

However, a sufficiently large authorized-delegate program may increase the principal's regulatory exposure, transaction volume or bonding requirement in a particular jurisdiction.

Where that happens, the authorized-delegate agreement may allow the principal to pass through some incremental cost attributable to the delegate.

The important lesson is not that an increase will necessarily occur.

It is that the agreement should explain who pays if the delegate's activity causes additional:

• bond premiums;

• reserves;

• insurance;

• regulatory fees; or

• compliance costs.

This issue becomes more relevant as volume grows.

34. The Authorized-Delegate Agreement

The authorized-delegate agreement is the core legal instrument.

It should be reviewed carefully.

Important provisions commonly include:

• scope of appointment;

• territories;

• permitted products;

• approved customer types;

• funding methods;

• payout methods;

• compliance obligations;

• AML responsibilities;

• audit rights;

• data access;

• cybersecurity;

• transaction monitoring;

• reserves;

• settlement;

• prefunding;

• fees;

• reconciliation;

• complaints;

• regulatory cooperation;

• branding;

• marketing approval;

• subcontractors;

• payout partners;

• indemnification;

• limitation of liability;

• insurance;

• personal guarantees, if any;

• suspension;

• termination;

• post-termination obligations; and

• record retention.

The commercial team should not review this agreement in isolation.

Compliance, legal, finance, treasury and technology should all understand the obligations being created.

35. Books and Records Must Be Excellent

The delegate should operate on the assumption that its records will eventually be audited.

Transaction records should allow a reviewer to reconstruct the transaction from beginning to end.

A complete record may need to demonstrate:

• customer identity;

• authentication;

• funding source;

• transaction amount;

• applicable exchange rate;

• applicable fees;

• compliance decisions;

• screening results;

• transaction timestamps;

• payout beneficiary;

• payout destination;

• proof of delivery;

• settlement;

• refunds;

• returns;

• complaints; and

• exceptions.

The delegate's accounting records must also reconcile to the principal's records and bank movement.

Poor reconciliation is one of the fastest ways to destroy confidence in a payment program.

36. Regulators, the Principal and the Delegate

The relationship can be understood as a chain:

State/Federal Regulatory Framework

↓

Principal License Holder

↓

Authorized Delegate

↓

Customer

The principal has direct licensing obligations.

The delegate operates within the principal's program while retaining compliance obligations appropriate to its activities.

The customer interacts primarily with the delegate's product.

Therefore the delegate must behave operationally as part of a regulated financial institution even if its own corporate name is not the name appearing on the underlying state money-transmitter licenses.

37. Why Starting as an Authorized Delegate Can Be Strategically Valuable

The authorized-delegate model is not necessarily the final destination.

For many fintechs, it can be the first stage of a U.S. regulatory strategy.

It offers an opportunity to learn:

• U.S. compliance;

• transaction behavior;

• state requirements;

• ACH;

• fraud;

• customer acquisition;

• banking;

• settlement;

• reconciliation;

• examinations;

• regulatory reporting; and

• product economics

before spending the capital and time required to build an independent multi-state licensing footprint.

A company may therefore follow a progression such as:

Stage 1 — Authorized Delegate

↓

Stage 2 — Establish U.S. Operating History

↓

Stage 3 — Expand Products and Corridors

↓

Stage 4 — Determine Whether Independent Licenses Make Economic Sense

↓

Stage 5 — Apply for Own Licenses Where Strategically Appropriate

Operating successfully as an authorized delegate can create a meaningful compliance track record.

It does not guarantee future licensing approval, but it can demonstrate that the applicant already understands the market and has previously operated under regulated supervision.

38. Corridor Expansion

Once the first corridor is working, the delegate can consider expansion.

Do not assume that authorization for one corridor means automatic permission to launch every other country.

Before activating another destination, evaluate:

• sanctions;

• local licensing;

• payout partners;

• bank coverage;

• settlement currency;

• foreign exchange;

• transaction limits;

• fraud;

• AML risk;

• source-of-funds risk;

• destination-country risk;

• payout speed;

• liquidity;

• data;

• pricing; and

• principal approval.

The objective is controlled expansion rather than uncontrolled geographic proliferation.

39. Product Expansion Beyond P2P

The U.S. market may ultimately support far more than consumer remittance.

Potential future use cases could include:

• B2B cross-border payments;

• supplier payments;

• contractor payments;

• marketplace payouts;

• payroll-related payments;

• collection products;

• treasury payments;

• merchant settlements; and

• additional permissible money-movement products.

Each new activity must be reviewed independently.

An existing authorized-delegate agreement should never be assumed to automatically cover a new product merely because the same API can technically process it.

40. Recommended Onboarding Sequence

A disciplined onboarding process can broadly follow this sequence:

Phase 1 — Principal Selection

Identify principals whose:

• licensing footprint;

• product capability;

• banking;

• risk appetite;

• corridors;

• pricing; and

• technology

match the proposed business.

Phase 2 — Introduction

Provide an initial business profile and conduct the introductory call.

Phase 3 — NDA

Execute confidentiality documentation.

Phase 4 — Due-Diligence Package

Submit corporate, ownership, financial and compliance information.

A well-organized applicant should aim to return documentation quickly rather than allowing due diligence to drag on because documents arrive piecemeal.

Phase 5 — Compliance Manual Review

Map the principal's requirements against the proposed customer journey.

Phase 6 — Commercial Review

Negotiate:

• fees;

• minimums;

• billing commencement;

• reserves;

• guarantees;

• prefunding; and

• pass-through costs.

Phase 7 — Technical Access

Obtain developer documentation and sandbox access as early as permitted.

Phase 8 — Architecture

Finalize:

• KYC;

• funding;

• data flows;

• transaction logic;

• payout;

• settlement;

• reconciliation; and

• reporting.

Phase 9 — Authorized-Delegate Agreement

Finalize the agency agreement and related schedules.

Phase 10 — State/Program Activation

The principal completes the applicable internal and regulatory steps required to activate the delegate.

Phase 11 — Training

Complete compliance, operations and system training.

Phase 12 — Testing

Conduct end-to-end test transactions.

Phase 13 — Production Approval

Receive production credentials and final approval.

Phase 14 — Controlled Launch

Begin with limited customers, transaction sizes and corridors.

Phase 15 — Monitoring and Expansion

Review operational performance before increasing limits or introducing additional markets.

41. What the Technical Team Should Ask

Before development begins, engineering should obtain answers to questions including:

• Who owns the customer onboarding UI?

• Where is KYC collected?

• Who actually performs identity verification?

• Which data must be transmitted to the principal?

• Which information is returned?

• Where can customer information be stored?

• What authentication methods are required?

• Is account verification integrated?

• How is ACH initiated?

• How are transaction limits communicated?

• How are compliance holds communicated?

• How are rejected transactions handled?

• How are refunds processed?

• How are ACH returns reported?

• Which webhooks exist?

• How are beneficiary details submitted?

• How is proof of payout returned?

• How are ledger records reconciled?

• What files or reports are generated daily?

• What happens during API downtime?

• Are there idempotency requirements?

• How are test and production credentials separated?

• What logging must be maintained?

• What information may not be logged?

• What encryption standards are required?

• What penetration-testing requirements exist?

These questions should be answered before the application architecture is frozen.

42. What the Compliance Team Should Ask

Compliance should independently understand:

• permitted states;

• prohibited states, if any;

• permitted transaction types;

• customer eligibility;

• KYC standards;

• sanctions screening;

• PEP handling;

• enhanced due diligence;

• transaction limits;

• source-of-funds requirements;

• transaction monitoring;

• manual-review triggers;

• suspicious-activity escalation;

• record retention;

• regulatory reporting allocation;

• customer complaints;

• error resolution;

• refund procedures;

• receipt requirements;

• disclosures;

• advertising rules;

• state-specific language;

• training requirements;

• audit rights;

• examination procedures; and

• incident reporting.

The objective should be a written responsibility matrix identifying:

Principal Responsibility

Delegate Responsibility

Shared Responsibility

Ambiguity is dangerous.

43. What Finance and Treasury Should Ask

Finance should understand:

• where customer money lands;

• when funds become available;

• settlement timing;

• prefunding requirements;

• reserve requirements;

• ACH return exposure;

• reconciliation;

• foreign exchange;

• settlement cutoffs;

• weekend and holiday treatment;

• correspondent charges;

• payout liquidity;

• minimum balances;

• account ownership;

• fees;

• invoice frequency;

• chargebacks;

• losses; and

• negative-balance procedures.

A technically functioning payment system can still fail if treasury is poorly designed.

44. What Management Should Measure After Launch

Management should receive regular reporting covering:

• active customers;

• new customers;

• transactions;

• payment volume;

• average transaction value;

• revenue;

• transaction cost;

• gross margin;

• KYC rejection rate;

• compliance-review rate;

• fraud rate;

• ACH return rate;

• payout failure rate;

• average payout time;

• complaints;

• refunds;

• customer-acquisition cost;

• corridor profitability;

• prefunding utilization; and

• reconciliation exceptions.

This information should be broken down by corridor and funding method wherever possible.

45. Common Mistakes

Several mistakes repeatedly cause authorized-delegate programs to fail or become unnecessarily difficult.

Treating the Arrangement Like API Sponsorship

It is an agency relationship, not merely technology access.

Overcomplicating the Initial Structure

Multiple entities, corridors, banks and payment methods create unnecessary friction.

Building Before Reading the Compliance Manual

The customer journey may need to be redesigned.

Assuming Existing KYC Can Automatically Be Reused

The principal may require its own verification framework.

Ignoring Settlement Risk

Authorization is not always the same thing as irreversible money.

Underestimating ACH Fraud

ACH is useful, but return and dispute exposure must be modeled.

Sending Funds to Unrelated Accounts

Funds flow should follow the licensed and contractual structure.

Making Unrealistic Volume Claims

Credibility is more valuable than oversized projections.

Accepting the First Commercial Proposal Without Analysis

Pricing should be evaluated as an entire economic package.

Ignoring Billing Commencement

Several months of fees before launch can materially change project economics.

Accepting Personal Guarantees Casually

They should be understood and negotiated.

Assuming the Principal Owns All Compliance

The delegate remains part of the regulated compliance chain.

Expanding Too Quickly

A stable first corridor is more valuable than ten unstable corridors.

46. Frequently Asked Questions

What exactly is an authorized delegate?

An authorized delegate is an agent appointed by a licensed money transmitter to conduct specified money-transmission activities on the principal's behalf, subject to applicable state law, the principal's licenses and the authorized-delegate agreement.

Does becoming an authorized delegate give me the principal's licenses?

No.

The licenses remain owned by the principal.

Your authority exists through the agency relationship and applicable regulatory framework.

Am I "renting" the principal's licenses?

That terminology should be avoided.

A legitimate authorized-delegate relationship involves supervision, compliance controls, contracts, regulatory obligations and principal oversight.

It is not simply passive license rental.

Is this the same as Banking-as-a-Service or using a payment API?

No.

A payment API provides technical capability.

Authorized-delegate status addresses the regulated agency relationship under which the money-transmission activity is conducted.

Can I use my own brand?

Often yes, subject to the principal's requirements.

The principal may require particular disclosures explaining who provides the regulated money-transmission service.

Can I use my own mobile application?

Usually this is possible, but the U.S. customer experience must conform to the principal's compliance and technical requirements.

Can I use my existing KYC provider?

Maybe.

Some principals require their own KYC or approved verification process.

Others may allow the delegate to collect the information while the principal's system performs the verification.

This should be confirmed before development.

Does the principal interact with regulators or do I?

The principal generally manages the core state licensing relationship and applicable reporting framework.

However, the delegate must maintain compliant operations and records and may be subject to audit, examination or regulatory scrutiny.

Do I need my own FinCEN registration?

If the company is an MSB solely because it acts as an agent of another MSB, FinCEN generally does not require a separate MSB registration. If the company conducts MSB activities independently, the analysis changes. (FinCEN.gov)

Does that mean I have no AML obligations?

No.

FinCEN guidance emphasizes AML responsibilities for both MSB principals and agents. Contractual allocation of tasks does not automatically eliminate the underlying compliance responsibility. (FinCEN.gov)

Who files suspicious-activity reports?

The exact operational allocation should be defined in the AML program and agreement. FinCEN has stated that responsibility may involve both the principal and agent, while duplicate reporting for the same information should generally be avoided. (FinCEN.gov)

This is why the responsibility matrix between principal and delegate matters.

Will I have to comply with every state's rules?

You must comply with the requirements applicable to the program in the states in which you operate.

In practice, the principal usually translates these requirements into its compliance manual, technical specifications and operating procedures.

Why do receipts differ?

Federal remittance rules impose certain requirements, and additional state requirements may apply.

The principal's compliance program should specify the correct disclosure format.

Can customers cancel a remittance within 30 minutes?

For qualifying remittance transfers, federal law generally provides a 30-minute cancellation right after payment if the statutory conditions are met. The right does not apply once the funds have already been picked up or deposited into the recipient's account. (Consumer Financial Protection Bureau)

Can the delegate touch customer funds?

An authorized-delegate arrangement can permit the delegate to participate in funds movement within the principal's approved framework.

Exactly how funds are controlled, held and settled depends on the agreement, state law, banking architecture and program design.

Can I connect directly to my own bank?

Not for regulated program transactions unless the structure has been specifically approved.

The principal must maintain sufficient control and visibility over transactions conducted under its licenses.

Who provides the bank account?

This varies by principal.

The program may include a settlement, pooled, custodial or FBO-style banking structure.

The exact account architecture must be documented.

Can settlement go into another company in my corporate group?

Only if the principal specifically approves that funds flow and the structure is legally and operationally defensible.

Do not assume that settlement can simply be redirected to a sister company.

Who handles foreign exchange?

This is program-specific.

In some structures the principal deals entirely in U.S. dollars and the authorized delegate or regulated foreign payout entity manages the destination-side FX and payout economics.

Can I add countries later?

Usually yes, subject to the principal's approval and the regulatory, compliance, sanctions, banking and payout analysis for each additional corridor.

Should I launch several corridors immediately?

Usually not.

Start with the simplest corridor and prove that the complete operating model works.

Then expand.

Do I need prefunding?

If you intend to pay beneficiaries before incoming customer funds have completely settled, somebody must provide the liquidity.

That is normally the delegate's responsibility unless the parties specifically agree otherwise.

Why not simply wait until the customer's funds settle?

You can.

That is the safest settlement-risk model.

The tradeoff is customer experience and payout speed.

What is "funds good and settled"?

It means the incoming funding transaction has actually settled rather than merely having been authorized or initiated.

Is ACH risky?

ACH is widely used and can be very effective, but returns and disputes exist.

The program should therefore use appropriate account verification, authentication, transaction monitoring and fraud controls.

Does account verification eliminate ACH fraud?

No.

It materially improves the risk framework but cannot eliminate authorized-payment fraud, account takeover, first-party fraud or later disputes.

Will the principal require a reserve?

Possibly.

Reserve requirements depend upon funding methods, fraud exposure, transaction volume, credit risk and the principal's underwriting policy.

Will I need a surety bond?

The principal maintains the surety bonds associated with its state licensing framework.

However, contracts may allow incremental bonding or regulatory costs attributable to the delegate's activity to be passed through.

Should I give a personal guarantee?

A personal guarantee should never be treated as a trivial onboarding form.

If requested, understand its scope and negotiate it.

Can monthly minimums be negotiated?

They often can be.

The most important questions are not merely the final monthly minimum but also the ramp-up schedule and the date on which billing begins.

When should API development begin?

As soon as the principal permits access to the sandbox and technical documentation.

Ideally, technical evaluation should run in parallel with compliance due diligence.

Can our servers remain outside the United States?

Potentially, but this must be reviewed against the principal's requirements, banking requirements, applicable privacy/cybersecurity rules and cross-border data-transfer obligations.

Do not assume the answer.

Who owns the customer?

Commercial customer ownership, data rights and post-termination rights should be explicitly addressed in the agreement.

Do not leave this ambiguous.

Can the principal terminate the program?

Typically yes, subject to the agreement.

Because the principal's licenses are being used, it needs the ability to suspend or terminate activity presenting unacceptable regulatory, compliance, fraud or financial risk.

Business-continuity planning should therefore consider principal dependency.

Can I eventually obtain my own state licenses?

Yes.

For some businesses, authorized-delegate status is deliberately used as the first phase of a longer U.S. licensing strategy.

Operating successfully as a delegate gives the company practical experience before embarking upon its own state licensing program.

Does being an authorized delegate guarantee that regulators will later approve my own licenses?

No.

It can create useful regulatory operating history, but every license application remains subject to the regulator's independent review.

47. Final Readiness Checklist

Before going live, the company should be able to answer yes to the following:

• The exact authorized-delegate entity has been selected.

• Corporate ownership has been fully disclosed and verified.

• The authorized-delegate agreement has been executed.

• The permitted states are documented.

• The permitted products are documented.

• The initial corridor has been approved.

• Destination-side licensing has been verified.

• The payout structure has been approved.

• The flow of funds has been documented.

• Settlement-account ownership is clear.

• Prefunding requirements are understood.

• Reserve requirements are understood.

• Pricing has been negotiated.

• Billing commencement is documented.

• Any personal guarantee issue has been resolved.

• Incremental bond/regulatory-cost treatment is understood.

• The principal's compliance manual has been reviewed.

• Principal/delegate compliance responsibilities are documented.

• AML personnel have been trained.

• KYC architecture has been approved.

• Sanctions architecture has been approved.

• Transaction-monitoring rules have been approved.

• ACH risk controls have been implemented.

• Fraud limits have been configured.

• Customer receipts have been approved.

• Federal and applicable state disclosures have been implemented.

• Cancellation procedures have been implemented.

• Error-resolution procedures have been implemented.

• Complaint procedures have been implemented.

• API integration has been completed.

• Sandbox testing has passed.

• Production credentials have been issued.

• Data-storage architecture has been approved.

• Cybersecurity requirements have been satisfied.

• Reconciliation procedures have been tested.

• Proof-of-payout reporting works.

• Customer-support personnel have been trained.

• Compliance escalation procedures have been tested.

• Treasury has sufficient liquidity for launch.

• Initial transaction limits have been approved.

• Management reporting has been established.

• A controlled production-launch plan exists.

Conclusion

Becoming an authorized delegate is one of the most practical ways for a capable payments company to enter the regulated U.S. money-transmission market without immediately undertaking a full independent multi-state licensing exercise.

But the real value of the model is frequently misunderstood.

The principal is not merely providing an API.

The delegate is not merely purchasing regulatory coverage.

The arrangement is an integration of:

licensing + agency + compliance + banking + technology + settlement + fraud management + regulatory supervision.

Companies that understand this from the beginning generally approach the process very differently.

They simplify the structure.

They select one initial use case.

They prepare their due diligence properly.

They read the compliance manual before designing the final product.

They obtain sandbox access early.

They negotiate economics rather than merely accepting the first proposal.

They understand settlement and prefunding.

They build strong books and reconciliation.

They treat fraud as an economic reality.

They maintain excellent compliance records.

And only after the first structure works do they begin adding complexity.

That is the correct progression:

Simple first.

Compliant first.

Operational first.

Scale second.

Once that foundation exists, an authorized-delegate arrangement can become much more than a mechanism for launching one remittance corridor. It can become the regulated foundation from which a company learns the U.S. market, expands products and geographies, develops a regulatory track record, and eventually determines whether building its own independent licensing footprint is commercially justified.