BaaS & Payments Platform

Context

In the early 2020s, market demand for Banking-as-a-Service (BaaS) platforms was high, and MainStreet Bank, a $2.2 billion community bank in Fairfax, Virginia, answered by launching a dedicated fintech subsidiary: Avenu, with its own P&L, its own go-to-market strategy, and its own operating model.

A bank launches a BaaS division for a number of business opportunities. Low-cost deposits: partner-sourced deposits are cheaper funding than CDs or loans. Fee income: transaction and program fees, diversifying revenue away from net interest margin. New markets: partners reach segments a physical branch footprint can't. The original plan for Avenu called for roughly $200 million in deposits after three full years of operation, a yardstick worth naming now, because the outcomes outlined in this case study report against it.

The $200 million deposit goal was a division-level target, set at charter the way a board sets one for any new business line: a number to build toward, established before there was a pipeline to build it from. That sequence is ordinary, and it is worth naming, because deposits in a sponsor-bank model arrive only through partners, at a pace those partners set and in volumes no bank can verify in advance. The work of turning a target into a plan therefore happens after the target exists, against a pipeline still being assembled. Two constraints shaped the business strategy. First, the bank, not the fintech, owns the regulatory obligation: every partner's end customer is the bank's customer for BSA, KYC, AML, and sanctions purposes. And second, every compliance control adds friction to the onboarding volume for all three opportunities (low-cost deposits, fee income, and new markets). The regulatory and industry requirements were substantial: Federal Reserve fintech guidance, BSA/AML, NACHA, PCI-DSS, and SOC 2, all of which any fintech in the space needs to tackle successfully.

Taking ownership

I joined about six months in, as SVP, Director of Product Management. The business model thesis, the charter, projections, target market(s), the build vs. buy structure, and the original build timeline predated me. What did not yet exist was a platform in production, an in-house team to build one, or a roadmap the division could plan against. In a new division, a product role quickly expands to cover whatever the business can't yet do for itself. I ended up directly managing product management; program management; customer success (fintech onboarding, technical support, Salesforce development, Partner Portal and mobile app development, training, and fintech reporting requirements); BaaS business continuity planning; and much of the process and technical documentation for the division. I partnered with bank leadership on fintech banking services, sales, risk management, cyber security, and compliance.

A pivotal decision came around the one year mark. Platform development sat with a prime contractor, and by then the pattern was unmistakable. The unglamorous functionality that separates a demo from a production banking system kept landing outside what the engagement would deliver: field validation, input sanitization, edge-case handling, sad-path test scenarios. Each deferral may have had a contractual justification; however, the accumulation was a platform that could be shown but not operated, and that gap was not going to close by managing the relationship harder.

Both parties were behaving rationally inside a structure that couldn't converge. In practice that meant managing two partners whose incentives were misaligned by construction, from my first day. After a year of it, the conclusion was clearly structural rather than managerial: the contract's definition of done and the platform's had diverged, and closing the difference would have meant spending additional time and resources renegotiating for every gap. More time, more discussion, and more pressure would not have reached a production platform.

I made the case to leadership to change course: end the contracting arrangement, hire an in-house team, and complete the platform ourselves. The plan was approved. Executing the plan meant running the transition without pausing a live regulated platform: recruiting and standing up multiple development teams; knowledge sharing around code, architecture, and the undocumented operating knowledge that never appears in a deliverables list; and holding compliance coverage and its evidence trail continuous throughout, because a gap there is a finding whether or not anything broke. The transition completed incident-free: no gaps in operations, no outages, and nothing that produced an examiner surprise. The honest cost belongs in the same breath: a program that replaces its delivery model and development team mid-build spends significant time doing it, out of a fixed window it does not get back.

Operating model

Product owned the roadmap. Key bank departments owned inputs, each with a standing seat rather than a review gate. Sales' pipeline drove fintech selection. Operations supported the bank-fintech business relationship. Compliance managed the case and alert queues and the procedures that translated into acceptance criteria reviewed at spec time. Risk Management set the monitoring thresholds. Cyber Security reviews were part of the ongoing security posture bar a fintech had to clear and maintain.

Development was organized into five portfolios, each with its own backlog; most teams ran on a shared two-week release train:

• Engineering Team: DevOps, infrastructure, platform security, performance, and scalability, owned as a product rather than a service desk. In a chartered bank, availability and security controls are examinable.
• Compliance Team: the customer onboarding workflow itself, plus BSA/AML, KYC/KYB, sanctions screening, transaction monitoring, case management, and audit evidence. A product team with a roadmap, not a review board; one team, because the workflow is the KYC decision path. The remit ran across onboarding, compliance, and risk; the simplified name was deliberate, so everyone in the bank knew who owned it.
• Payments Team: money movement: ACH, debit card, internal customer-to-customer transfers, the payment gateway, the ledger, settlement, returns, and exceptions.
• New Services Team: new capability on the platform, primarily debit cards: issuing, activation, authorization, and disputes.
• Customer Success Team: partner activations, including the fintech certification process (the integration, compliance, and cyber security milestones a partner had to pass before onboarding customers), and every surface a partner's experience of the bank ran on: the Fintech Onboarding, Partner Portal, Fintech Reporting, Technical Support, Fintech Training, and the developer API documentation. The name was deliberate: those surfaces are the product for everyone except the end customer.

Engineering controlled development practices end to end, which is why compliance work could ship on the same two-week release train as payments. Risk management and cybersecurity ran on a third axis: centrally tracked and managed, while mitigation projects were woven into whichever team's backlog owned the affected domain. And then the part of the operating model that explains the most and appears in the fewest case studies: every team was paired with a senior business leader who informed its prioritization calls, and each team was accountable for that domain's outcome.

Putting the bank's risk leadership over the compliance-and-onboarding backlog is a large part of why the regulatory record below reads the way it does. It also means the onboarding workflow, the path every partner had to clear to become deposits, was sequenced against regulatory exposure rather than against the ramp, exactly what a bank should optimize for. Priorities follow accountability, and every leader in the model was right inside their own frame. What that does to an outcome that cuts across every backlog is the subject of the last two sections of the case study.

What we built

The ledger deserves a sentence of defense. Our ledger technology was tied straight to core: the design a third-party audit described as guaranteeing the accuracy of the transaction ledger, and the exact thing that broke most middleware-dependent BaaS programs elsewhere.

The compliance program is what made the platform valuable: partners were leveraging the bank's compliance posture as much as its rails. KYC/CIP for individuals, with verification vendors orchestrated behind one internal decisioning service, so a vendor swap (or a raised bar) was an integration, not a complete rebuild. Risk-based tiering drove enhanced due diligence, with thresholds owned by Compliance. OFAC screening ran at onboarding, on a rescreening cycle, and in real time on the payment path, screening the parties a payment actually touches. Transaction monitoring and fraud detection shared the same surface, and real-time money movement is what makes it hard: instant and irrevocable means the decision happens inline, within a latency budget, before the transfer posts. All of it produced examination evidence by design.

One more build decision no reader expects from a bank: we dogfooded our own APIs with a real application. We hired a full-stack mobile developer, a single FTE, who built and maintained an internal-only consumer test mobile application (React Native) that consumed the platform's partner APIs exactly as a fintech would. It caught issues in third-party vendor infrastructure before a partner could, caught defects in our own APIs that the test suites had missed, gaps in fintech certification test scenarios, and, in the largest category and the one no test suite can produce, surfaced subtle friction in the integration experience itself: steps that may be technically documented, but confusing in practice or wording. In a BaaS platform the API is the product, and dogfooding is how a platform team quickly learns what its API costs to adopt.

What we held the line on

Three decisions set the platform's risk posture. Each was made deliberately, each held under pressure to do otherwise, and each cost deposits.

• A bounded launch surface: B2C fintech programs, funding via ACH and debit card, ACH and consumer-to-consumer payments, and a selected first wave of enterprise partners rather than an open front door. Credit card rails were sequenced behind the richer controls they require: in a sponsor-bank model, going live with rails you can't yet control is exactly how the other banks that ran afoul of their regulators got there.
• A certification gate with teeth: integration, compliance, and cyber security milestones stood between signing a partner and putting it live, the cyber security standards shared in full before contracts were signed. A significant share of signed partners never cleared it, and we did not put them live anyway.
• No partner the platform could not yet supervise: including prospects large enough to move the deposit plan by themselves, whose requirements ran past the controls we had built. Serving them safely meant building first.

The clean regulatory record below is what those three decisions bought. Their price, in the same breath: a narrower compliance surface reaches fewer fintech partners, funds fewer deposits, and serves the partners with the simplest needs. The sequencing that protected the regulatory record also constrained the revenue ramp, and the last two sections of this case study price that in full.

The two-sided compliance workflow

The most distinctive product story on the platform starts from an awkward fact of the BaaS model: two compliance departments look at the same alert. The bank carries the regulatory obligation; the fintech knows its own customer. Neither can resolve alerts alone, and email and spreadsheets don't survive an examination.

So we built one workflow that both organizations work inside: alert queues, case creation and assignment, evidence and document collection, dispositions, SLAs, hand-offs between partner and bank reviewers, and a complete audit trail of who decided what and when. Permissioning was the hard part: partners see and act on their own customers' cases, while the bank retains oversight of everything and the final disposition.

It mattered commercially as much as operationally: Sales could sell to fintechs without a mature compliance function, because the platform gave them one to work inside, and bank staff could scale review without headcount growing linearly with partner count.

A moving target

Building began in 2021. Over the next three years, supervisory expectations for bank-fintech partnerships rose steadily: sharpened third-party risk expectations and, after failures elsewhere in the sector, firmer expectations around ledger integrity, reconciliation, and end-customer recordkeeping. The measured version is also the accurate one: the bar rose because the sector's user base and payment volumes were rising rapidly. That is regulation doing what it is supposed to do, which is protect consumers and their deposits, but a more interesting question isn't whether the bar should have risen; it's what a rising bar does to an original launch plan.

What it does is influence the backlog from outside, on a schedule the roadmap doesn't set. Some functionality defensible as v2+ at kickoff turned into table stakes during the v1 buildout. And not every raise came from a regulator: a large prospective fintech's requirements are a de facto standard too, and meeting them meant building controls the platform didn't yet have. The Compliance team was a formal priority and had its own development capacity, so new initiatives landed quickly in a development backlog rather than an out-of-cycle escalation. Enhancement requests landed next to the onboarding workflow they would slow down, keeping the friction visible to the team adding them.

The strategic read, and the hinge of this whole case study: the compliance bar was a deep moat, and a moat is a cost to build and maintain. Clearing it is exactly why Avenu avoided the regulatory failures that ended numerous peers. The cost of clearing it is a large part of why the economics for Avenu never closed. The same wall that kept competitors out kept the return on invested capital away.

How we worked

Two-week shared release cadence across the platform dev teams, including the compliance team's work, which is the part people don't expect. Spec-first delivery: compliance obligations written into specifications and acceptance criteria and reviewed by Compliance and Risk before build. Regular executive and board reporting covered health, milestones, KPIs, and risk, the same measures every month, which is what kept the reporting credible when the numbers were reviewed.

The planning model changed with the delivery model, and this is the clearest thing the change bought. Under the contractor there was no dependable forward roadmap: with the work the platform needed sitting outside what the engagement would deliver, sequencing stayed reactive and dates were estimates nobody could stand behind. With the teams in-house I instituted disciplined portfolio planning across the five backlogs: each team estimating its own work against the shared release train, with capacity and cross-portfolio dependencies visible at planning time. The teams estimated reliably enough that the division ran a platform roadmap 18 months out and planned against it. A bank can only weigh regulatory exposure against a revenue ramp if it knows what each one costs in delivery time; that roadmap is what made the trade in the last two sections a decision rather than a guess.

Outcomes: two scoreboards

What the platform achieved

I took a build that could not converge to done and delivered it into production: a BaaS platform at a federally regulated institution, built from the ground up rather than assembled on middleware, by an in-house team stood up mid-program. Services kept compliant with Federal Reserve guidance, BSA/AML obligations, and NACHA, PCI-DSS, and SOC 2 industry requirements, on a two-week cadence, while the requirements moved. A delivery organization that could estimate reliably enough to run an 18-month platform roadmap, where the prior model had produced no dependable forward plan at all. A division stood up whole: sales channel, onboarding program, customer and technical support, training, enterprise reporting, business continuity planning, and the processes to run all of it. And a clean regulatory record in a cohort defined by the opposite. American Banker, reporting the shutdown:

“Many of the institutions that encountered difficulties in the banking-as-a-service business ran afoul of their regulators. MainStreet avoided those pitfalls, building Avenu from the ground up, stressing compliance and linking fintech partners directly to its core banking system to guarantee the accuracy of the transaction ledger.”

American Banker · April 2025

What the business didn't

Deposits reached roughly $41 million at year-end 2024, against the ~$200 million three-year plan. The unit lost $3.6 million in 2024. In Q4 2024 the bank recorded a $19.7 million impairment of Avenu's operating software. An impairment is a statement about the business case, not a defect report: it writes an asset down when the expected returns disappear, and it is the plainest available measure of what building rather than renting cost. The division was wound down in April 2025, after four years. CEO Jeff Dick, on the decision:

“The timeline for the expected return on invested capital extended beyond the Company's plan, and we decided to devote our energy on the core bank.”

Washington Business Journal · April 2025

The wind-down was also a layoff: the people on those teams delivered a regulated platform from nothing and kept its examination record clean the whole way, and what failed was the business case, not their work.

Both scoreboards in one sentence: the platform cleared the bar that ended its peers, and the business never reached the scale that would have paid for clearing it.

Why it ended

The proximate cause is public and unambiguous: deposits and revenue arrived far below plan, the return timeline stretched past what the board had underwritten, and a $2.2 billion community bank redirected its energy to the core bank. It wasn't idiosyncratic: a cohort of community banks discovered the same economics at roughly the same time. The more useful question is where, mechanically, the ramp went missing.

Where the ramp went missing

Two failures compounded inside the launch cohort, neither of them a platform failure. A significant share of the launch partners never went live: they cleared due diligence and signed, but didn't pass the certification process that stood between signing and going live. Cyber security was one hurdle several partners failed to clear. The standards went to partners in full before a contract was signed, so the bar was never a surprise; what it asked was that a fintech operate at a bank's security posture, and in practice most early-stage companies were not equipped to reach it. Knowing the bar and being able to clear it turned out to be different problems. A partner that can't clear that gate is one the bank shouldn't put live. And the partners that did integrate brought materially fewer end customers than their own projections: not a delay, a different number. Fewer partners live than signed, times fewer customers per live partner than forecast: two haircuts on the same pipeline, the second applied to what survives the first. That is arithmetically how a plan lands at a fraction of target while the platform does what it was built to do.

Further up the pipeline sat a third dynamic: the sharpest version of the trade. Some prospective partners were large enough to move the deposit plan by themselves, and serving them safely required capability the platform had not yet built. Holding the standard while building toward that demand was right (the alternative was onboarding partners the platform couldn't yet supervise, the exact path to the sector's enforcement actions), and it also cost the division its two scarcest resources at once: deposits it didn't book, and months it didn't have. The publicly stated reason for the shutdown is a return timeline that extended beyond plan; this is one concrete mechanism by which a timeline extends. The partners who could have closed the deposit gap fastest were also the ones whose requirements would take longest to build for.

Set the two failures side by side and the shape of the problem appears. The partners the platform could serve without further build sat in a band, and the same standard set both edges: below it, early-stage fintechs that could not reach a bank's security posture; above it, the prospects whose requirements ran ahead of the controls. The addressable segment was narrower than the benchmark assumed, and it was narrow for the same reason the regulatory record was clean: both are what holding the standard produces. A $200 million target needed a market the platform could serve inside the window it had.

Months were scarce at both ends of the program, which is where the delivery-model change earlier in this story comes back. Ending the contract and building in-house was the right call and I would make it again; it was also expensive in the one currency a fixed-window program cannot replace. Those months came out of the same window the partner ramp needed, and a division that ends because its return timeline ran past plan does not get to count any of them as free.

What I'd own

Not the easy stories, because the facts rule them out: “they didn't know” is false, and the onboarding backlog wasn't mine to resequence; bank leadership prioritized it, correctly, against regulatory exposure. The division also carried a tension every bank knows: the revenue plan and the compliance obligation drawing on the same capacity.

And it wasn't an unraised question. The prioritization tradeoffs were weighed seriously, and leadership held course, because the largest prospective deals in the pipeline were predicated on building more compliance functionality. That wasn't a failure to decide; it was a decision: a bet on the pipeline the division was chartered to win. It didn't pay off. But I understood the logic then and I understand it now; in that seat, with those deals in view, I might have made the same call.

So what's left to own is the instrument, not the ask. Shared visibility and separate team backlogs are not ruthless prioritization, and neither, it turns out, is escalation. A reallocation case competing against a revenue thesis needs more than a capacity argument: it needs the activation funnel priced in the same currency as the pipeline: deposits per unit of integration capacity, against the expected value of the deals in waiting. I may have brought questions; I didn't bring the arithmetic that might have beaten the bet.

Ruthless prioritization is genuinely hard to implement in an enterprise, and hardest of all when all sides of the trade are right. Every backlog had an executive answering to something real (an examiner, uptime, customer activations, a revenue plan), and yielding capacity means absorbing risk in your own domain for a result you don't own. When judgment ties, the deciding argument has to be quantitative. So that is the instrument I bring now: a cross-cutting outcome gets named, instrumented, and priced from day one, in the currency the enterprise already optimizes, so the trade is settled on comparable numbers long before it has to become an escalation.

Closing Thoughts

• Don't outsource a 0-to-1 build in a regulated market. Contractors are only the right instrument for work whose shape is known and defined at signing; this work changed significantly every quarter. A contract precise enough to be enforceable and a scope loose enough to be right were mutually exclusive: whatever the contract enumerated became the boundary, and the work a production system turned out to need kept landing on the far side of it. Employees absorb that gap; a contract can't.
• Price the cross-cutting outcome in the currency the enterprise optimizes. An outcome that runs across every backlog (turning signed partners into transacting ones) belongs to no single list, and escalating it isn't enough: a reallocation ask that arrives as a capacity argument loses to a revenue thesis whenever the pipeline looks strong. Bring the arithmetic: what a unit of integration capacity returns in deposits, against the expected value of the deals the competing work protects, so the trade is decided on comparable numbers rather than on whose risk feels larger.
• Convert a top-down target into a bottom-up plan before the clock starts. A deposit target set for a division is a target, not a plan; it becomes a plan only when it is mapped to named partners, expected activation dates, and expected volumes. Then haircut that map twice: for the partners that won't clear diligence or certification, and for the end customers that won't materialize, because the partner projections feeding it are other companies' growth forecasts, submitted by companies that want the deal. Size the cost base against what survives both cuts, and say early and plainly when the arithmetic doesn't reach the number.
• Plan for the segment your control surface can serve today. The largest partners carry the most deposits and the most requirements; the two are the same fact. The smallest carry the fewest requirements of their own and the least capacity to meet yours. What is left between them is a band, and it is narrower than whoever sets the target will assume. Fund the capability up front, or size the plan to the partners you can onboard now; discovering the requirements deal by deal means paying in schedule, the most expensive currency a fixed-window program has. Treat each decision to close a capability gap as a timeline decision, not a scope decision.
• Test readiness; don't just disclose requirements. The cyber security standards went to partners in full before signing, and partners signed anyway, believing they could reach them. A bank's security posture is not something an early-stage company assembles after the contract is executed, so disclosure is not diligence: ask for evidence of the capability while you are still deciding whether to sign, in the form of controls already in place, audits already held, and named staff who own them. Then instrument the funnel like a funnel, so the drop between signed and live is visible while it is happening.
• Reserve significant capacity and time for regulatory changes and industry requirements from day one. The BaaS industry has a rising bar, and the moat is wider to cross than one can predict up-front.
• Build on your own API before you ask anyone else to. One engineer against the surface every dollar of revenue arrives through is the cheapest quality instrument a platform can buy.

The transferable lessons: in a regulated market, the barrier that protects you and the cost that sinks you are the same wall. Getting the product right up-front is crucial.

Todd Youngren, President of Avenu, on Brian’s leadership of the product organization:

“Brian Bretz was very impactful to our journey at Avenu to build a scalable, bank compliant Banking as a Service platform. As Director of Product Management, Brian brought clarity and structure to our product portfolio and go-to-market strategy, giving our teams a shared focus and a clear path to execution.”

Todd Youngren · President, Avenu · LinkedIn recommendation, July 2025

Sources

1. “Virginia community bank announces its exit from BaaS” · American Banker, April 2025 (may be paywalled).
2. “Fairfax's MainStreet Bank pulls plug on fintech subsidiary, lays off 20 employees” · Washington Business Journal, April 2025 (may be paywalled).

The figures on this page (the deposit gap, the 2024 loss, and the software impairment) come from the first of those; CEO Jeff Dick's statement on the wind-down comes from the second.