Embedded finance has moved from a product differentiator to a mainstream capability across vertical SaaS and marketplace platforms. The value proposition is real: incremental revenue, stronger retention, and a more complete product experience. But the compliance infrastructure required to support it is frequently under built.

The reason is often due to a persistent misreading of who bears regulatory responsibility. Platforms that embed payments, earned wage access, debit products, or deposit services often assume that regulatory exposure sits primarily with their sponsor bank or licensed processor. That assumption has become increasingly costly to maintain.

Regulators—including the Financial Crimes Enforcement Network (FinCEN), the Consumer Financial Protection Bureau (CFPB), the Office of the Comptroller of the Currency (OCC), and the Federal Deposit Insurance Corporation (FDIC)—evaluate compliance programs based on: 

  • Who controls the customer relationship
  • Who holds and processes the data
  • Who makes day-to-day operational decisions

In most embedded finance arrangements, that is the platform. Sponsor banks and card networks establish baseline requirements and conduct their own oversight, but they do not substitute for a platform’s own compliance program.

The following three questions are the practical test. Platforms that can answer them with specificity, documentation, and currency are well-positioned to scale. Those that cannot have identified the work ahead.

Question 1: Who owns each compliance obligation—and is that documented?

The division of compliance responsibility between a platform and its sponsor bank or payments processor is almost never self-executing. It must be negotiated, documented, and reviewed on a defined cadence.

Platforms should be able to point to a written agreement—whether embedded in a program agreement, a compliance schedule, or a separate responsibility matrix—that specifies ownership of each material obligation. At a minimum, that document should address:

  • Anti-Money Laundering (AML) program requirements, including suspicious activity monitoring, suspicious activity report (SAR) filing obligations, and the allocation of Bank Secrecy Act (BSA) duties between the bank and the platform.
  • Sanctions screening under OFAC, including the frequency, scope, and ownership of screening against SDN and other restricted-party lists.
  • Know Your Customer (KYC) and Know Your Business (KYB) procedures, including who performs identity verification, who makes adverse-action determinations, and who retains the underlying records.
  • Payment Card Industry Data Security Standard (PCI DSS) compliance scope, including which party is the merchant of record and which systems fall within the cardholder data environment.
  • Consumer protection obligations under applicable federal and state law, including error resolution, dispute handling, and disclosures.

Three criteria determine whether an answer to this question is sufficient. It must be: 

  1. Specific: Naming obligations and their owners rather than relying on general language)
  2. Written: Not carried informally from deal-closing conversations)
  3. Current: Reviewed within the last twelve months or the cadence required by the partnership agreement). 

If the document fails any of those criteria, that is the gap to close before the next audit or product expansion. Note that data privacy obligations, including those arising under the California Consumer Privacy Act (CCPA) and, for platforms with EU-facing operations, the General Data Protection Regulation (GDPR), are distinct from payments compliance obligations but often intersect with them. They should be addressed in a privacy program and not conflated with the financial regulatory framework.

Question 2: Can you independently verify what is happening in your customers’ accounts?

Compliance visibility is not a secondary concern in embedded finance but a foundational control. A platform that relies exclusively on its provider’s dashboard to understand customer balances, transaction history, and flag status has a structural gap in its oversight program.

Recent events across the industry have also reinforced the importance of platforms being able to independently verify the state of customer funds.. Regulators and plaintiffs’ counsel drew the same conclusion: the platform had insufficient controls over the financial activity it was facilitating.

A sound compliance monitoring program for an embedded finance platform should include:

  • Real-time or near-real-time transaction monitoring capable of detecting suspicious activity patterns, velocity limit breaches, and anomalies that may require SAR filing or account action.
  • An independent data feed or reconciliation mechanism that allows the platform to verify customer balances and transaction records without relying solely on the provider’s reporting.
  • Documented escalation procedures for flagged activity, including clear ownership of the decision to file, hold, or close.
  • Contractual SLAs with the sponsor bank or processor governing API availability, data access, and incident notification timelines. Technology capability alone is insufficient without enforceable contractual rights.

Vendor and partner selection should account for risk profile alignment, not only integration quality. A provider’s willingness to support the platform’s monitoring architecture, provide sandbox testing environments, and cooperate with regulatory examinations is as material as its API documentation.

Question 3: Do you have a dedicated operations team to run payments day-to-day?

Building a payments product is a distinct undertaking from operating one. The operational demands of embedded finance—disputes, chargebacks, fraud escalations, reconciliation failures, regulatory holds—require a clearly defined function with dedicated resources and documented procedures. If those roles do not appear on the org chart, the function has not been built; there is only a product.

Effective payments operations require coordination across teams that have not historically worked in close alignment. The compliance implications of that coordination are material:

  • Customer Support handles payment disputes, chargeback responses, and refund processing. These interactions carry regulatory and financial consequences that differ in kind from standard product support tickets. Staff handling them require specialized training, and response timelines are often legally prescribed.
  • Engineering builds and maintains the fraud detection and monitoring tooling. Gaps or failures in that tooling carry direct compliance exposure.
  • Product designs the payment flows, including the disclosures, consent mechanisms, and error resolution pathways that regulators will scrutinize.
  • Compliance owns ongoing monitoring, SAR filing, sanctions screening, and regulatory reporting—and must have sufficient visibility into Engineering and Product decisions to perform that function effectively.

Chargebacks deserve particular attention. They are among the most operationally frequent events in embedded payments and one of the most consistently underestimated. They are time-sensitive, carry financial penalties, and are governed by card network rules that impose their own compliance requirements distinct from federal or state law. Non-fintech platforms entering embedded payments frequently absorb the first wave of chargeback volume before their processes are calibrated to handle it.

Compliance as a scaling constraint

Each of the three questions above becomes harder to answer well as transaction volume, customer count, and product complexity grow. The cost of a well-documented compliance structure is front-loaded. The cost of an underdocumented one tends to materialize at the worst possible time—during a regulatory examination, a partner bank audit, or a major fraud incident. 

Compliance and legal teams should engage early in embedded finance product decisions, not as a downstream approval function but as a design participant. The obligation structure, monitoring architecture, and operational model are all easier to build correctly the first time than to retrofit under pressure.

A third-party partner, whether that’s a program manager, a compliance-as-a-service provider, or a specialized processor, can shorten  the path to a thoughtful and comprehensive program. The evaluation criterion should be whether the partnership produces an auditable, examiner-ready compliance structure, not merely whether it simplifies integration.

About Sunita Hall, Head of Compliance, AML/CFT at Branch

Sunita Hall is Head of Compliance, AML/CFT at financial infrastructure provider Branch, where she oversees compliance and BSA/AML functions as the company scales. Sunita brings extensive experience across fintech and traditional banking. Previously, she built compliance programs from the ground up, balanced innovation with regulatory requirements, and led global sanctions initiatives at several high-growth fintechs. She also has a decade of experience in Private Banking and Wealth Management, informing her work at the intersection of finance and technology.

About Branch

Branch provides workforce financial infrastructure, helping businesses and platforms manage the flow of worker payments and the operational processes surrounding them. Companies use Branch to power the movement of earnings to employees and independent contractors—including wages, tips, reimbursements, and other payouts—through financial technology that integrates into existing systems. Beyond facilitating payouts, Branch offers tools that support operational workflows connected to workforce payments. These tools help companies streamline processes, reduce manual work, and support administrative and compliance efforts. Branch powers workforce payments and financial services for many of the nation’s leading companies and platforms across hospitality, marketplaces, vertical SaaS, workforce management systems, and staffing. To learn more about Branch, visit https://www.branchapp.com and follow us on Twitter/X and LinkedIn.