Embed
Regulatory Structure
This was originally written for a sponsor bank partner
Background
ectors - from Credit and Compliance to Legal and Repetitional for the financial institutions that power many of these integrated payment programs. Not so good.Over the past decade, as “software ate the world,” embedded financial services, most commonly payments, have become deeply ingrained in software applications of all kinds. This ever-increasing surface area of payment access - which is good! - has somewhat predictably been met with escalated risk across multiple v
Much of this added risk is unforced and is the inevitable result of letting technology companies assume the significant compliance, risk management, and oversight responsibilities that come with being a payments company. These software or banking-as-a service platforms look to embedded payments and card issuance for additional monetization channels, differentiated in-app experiences, and increased end-user stickiness.
But to fully realize the benefits of embedded programs requires maintaining the high bar of compliance while navigating a complex - perhaps intentionally so - set of archaic Rules and Regulations set forth by disparate enforcement and regulatory bodies across various jurisdictions. Which is, frankly, a lot for even the most sophisticated organizations to handle.
It should then come as no surprise when a “growth-at-all-costs” startup, software, or fintech begins to map out a payments initiative, most times with the best of intentions, only to throw their collective hands up, when they come across something like this beauty from the 2023 Nacha Guidelines:
Third-Party what?
Third-Party Senders (”TPS”) are a subset of Third-Party Service Providers (“TPSP”) A Third-Party Sender is always a Third-Party Service Provider that acts on behalf of an Originator, but a Third-Party Service Provider does not always act as a Third-Party Sender. A Third-Party Service Provider is considered to be a Third-Party Sender when it acts as an intermediary between the ODFI and the Originator and there is no contractual agreement between the Originator and the ODFI. In this instance, the Third-Party Sender or Nested Third-Party Sender acts like the ODFI to the Originator. In any circumstance in which an Originator utilizes the services of a Third-Party Service Provider but has also executed a contractual agreement directly with the ODFI with respect to the origination of entries, the Third-Party Service Provider would not be considered a Third-Party Sender and would not be subject to the rule provisions governing Third-Party Senders. The Nacha Operating Rules require an agreement between the ODFI and the Third-Party Sender and between the Third-Party Sender and the Nested Third-Party Sender.
Content: 2023 Nacha Guidelines
Section: Section VI Special Topics
Subsection: Chapter 50 Third-Party Service Providers
SubSubsection: Role of the Third-Party Service Provider
What if, instead, the Company Building Really Good Software partnered with the Company Building Really Good Payments and they both focused on doing what they do best? What if?
Straddle Embed
Straddle Embed is a platform that, like , extends integrated payment infrastructure to , marketplaces, and even other PSP/PayFac providers. Embed simplifies the process of integrating bank payments and managing complex money movement scenarios within a software platform, app, or service. It is meticulously designed to support various account-to-account payment use cases and offers a complete suite of tools to facilitate payment acceptance, onboard customers, and streamline risk and operations.
Embed offers any platform or marketplace to extend Straddle payments with all the benefits of a “PayFac” or in-house program without any of the regulatory headaches, overhead, or significant liabilities that come with. This enables marketplaces and software vendors to embed Straddle within their applications to increase customer retention and provide a seamless experience for their users while benefiting from the advantages of a top-down compliance and risk program backing the next generation of A2A payments technology.
On the other hand, Embed enables Straddle to scale exponentially with each platform implementation and onboard small-business, low-tech, or “Main Street” businesses who typically lack the resources to build an API-first payment strategy but afford much higher margins than enterprise payments.
OK. But how?
Recent updates to the Nacha rules as detailed in Supplement #3-2021 and effective as of September 30, 2022, formally acknowledged the existence of “” and their role in the payments ecosystem.
“Oh.. Nested Third Party Senders. That’s cool,” you say, “but...
(deep breath) Nested TPS have long been a known, but poorly monitored source of latent risk for ODFI/Sponsor Banks and while the recent Nacha rule finally establishes a set of operating principles around these nested relationship the layered agreement structure simply pushes oversight down multiple levels from the ODFI to a potential daisy chain of third parties, each of which obfuscate granular originator activity and result in the same set of problems defined in the opening paragraph here only at larger scale which we’ve already established to be Not Great and how can we be sure each nested TPS has the right agreements and controls and exposure limits and annual audits and risk assessments and does the ODFI have to register each with Nacha and who has liability and what about AML? And what about WEB originator security audits? Supplementing Data Security Rule Phase Two - field level encryption of account data at rest? Enforcement of Commercially Reasonable fraudulent transaction detection system standards for first-time WEB Debits!?”
We agree; scary stuff. While nested TPS relationships may have a time and a place, policy is not a panacea for risk, and nested relationships may still introduce the serious monitoring and visibility issues that have long existed within this model. The dreaded “unknown, unknown.”
Straddle Embed eliminates the inherent risks of “Nested Third-Party Senders” while simultaneously extending the benefits of being a TPS to platforms building on Embed.
TPSP vs TPS
Remember that up at the top? Yes, still incomprehensible, but reading carefully holds the key to massively scalable embedded bank payments without sacrificing speed, ODFI visibility, or compliance. It’s all about the agreement structure, subsequent flow of funds, and corresponding obligations.
Before we go any further, let’s first take a step back in time and forget about nests and parties and platforms and APIs.
The year is 2014, NACHA (it was an acronym back then) publishes an update to the Rules that sets out to more specifically define Third Party Senders: ACH Transactions Involving Third-Party Senders and Other Payment Intermediaries – ACH Operations Bulletin #2-2014
The original graphic is perfect in its own right, so we’ve only made slight modifications in order to reference parties relevant to this discussion :
Put another way, this very standard set of agreements maps to something like this:
Maintaining the set of obligations and agreement structure (along with the oversight that comes with) defined above while introducing technology platforms as transparent intermediaries is the key to Straddle Embed.
Straddle implements the following points of control to maintain the appropriate agreement structure while appropriately positioning new intermediaries as Third Party Service Providers, not senders.
Embed Agreement
Endgame
That seems complicated
Yep! It was a massive undertaking to design, build, and implement. But now it’s reproduceable at scale. Every step following execution of a Straddle Payment Service can be completed within minutes. Demos available upon request.
Of course, while engaging, contracting and implementing a Embed Platform relationship has significantly more lead time than the “direct” Straddle users that may typically onboard via self-service/product-led sales, the cumulative effect of the Embed program will be massive on the long tail.
Why
The end result for each of our main characters:
Embed Platform - robust monetization (no interchange!) of differentiated embedded payments via out of the box payments-plus-compliance-and-identity-and-even-open-banking-as-as-service with “instant” onboarding via API and no compliance or regulatory overhead. Additional monetization/value adds from ancillary Straddle services like Identity Verification.
Embed Account - modern payment solution embedded in the software or service they use to run their business. From enterprise to daycare, with limited friction and built-in compliance.
Valley Bank (Sponsor Bank) - fully vetted, auditable payment program, with originator level visibility across all entities and payments. Collaborative environment with Straddle Ops/Compliance when investigations warranted. Diversified and robust, yet low-risk cashflow through Straddle accounts @ Valley. No visits from the OCC or CFPB
Straddle - $0/low CAC for embed accounts, economy of scale, diversified revenue base, partner bank with which to build innovative solutions and change how money moves
Story time
Amanda’s Day Care Center contracts the SaaS platform to handle its CRM and tuition management. After connecting to their bank account via a credential-based, “open banking” widget parents of students attending Amanda’s Day Care Center fill out a secure internet form that is powered by the software and agree to pay Amanda’s Day Care their child’s tuition on the first of every month.
formats the a monthly “tuition due” ACH file via tokenized API payload on behalf of the Amanda’s Day Care Center and forwards it on to Straddle, with which Amanda’s Day Care Center has a contractual agreement to originate ACH entries and to be bound to the Nacha Rules.
Straddle, a 3rd party sender, has an Origination Agreement with Valley Bank.
Straddle delivers the ACH file via SFTP to Valley Bank for processing through the ACH Operator, using Amanda’s Day Care Center as the value in the Company Name batch header field. On the effective date, funds are deposited into Straddle’s “FBO” account at Valley Bank
After a previously agreed upon hold period, Straddle sends a credit entry totaling the aggregate debit entry activity from the “process date,” less any returned items, to Amanda’s Day Care Center for their student’s monthly tuition payment.
Straddle also makes the results of Amanda’s Day Care Center available to via API so Amanda’s Day Care Center can better reconcile their payment activity and manage their business in a modern environment.
Amanda’s Day Care Center in this example is the Originator of the ACH because the parents (the Receivers) provided authorization to debit directly to Amanda’s Day Care Center.
is a Third-Party Service Provider performing a function similar to creating the “ACH File” file on behalf of the Originator and transmitting it to Straddle, which is a registered Third-Party Sender with Valley National Bank serving as the ODFI
In this scenario, however, is not a Third-Party Sender because a direct contractual agreement exists between Amanda’s Day Care (Originator) and Straddle (Third Party Sender) as well as Straddle and Valley Bank (ODFI). The direct agreement structure with Straddle - who while acting as a Third Party Sender acts “like the ODFI to an Originator” binds Amanda’s Day Care to the Nacha Operating Rules with respect to the origination of such transactions.
straddle
Denver, CO
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.