Dejan

Purpose-built accounts that let customers set money aside and spend it with their card – with real-time balance checks behind every swipe.

Product case study · Role: Product Manager · Domain: Consumer Fintech / Card Payments

TL;DR I led the product work on Spend Accounts – dedicated accounts customers can fund and spend from with their card, alongside their credit line. The feature required a real-time ledger, instant authorization decisions against account balances, and a funding flow built on ACH and debit rails. Within six months of full rollout, roughly a quarter of monthly active customers had opened a Spend Account, and funding volume grew steadily quarter over quarter.

The problem

Card customers increasingly want more than a single credit line. They want to set money aside for specific purposes – groceries, travel, a big purchase – and spend it without losing rewards, visibility, or control. Traditional issuers solve this poorly: customers end up juggling a separate bank account, a debit card, and a credit card, with no unified view of their spending.

Our hypothesis was simple: if customers could open dedicated Spend Accounts inside the same app and card experience they already use, they would consolidate more of their everyday spending with us, engage more often, and build a deeper relationship with the brand.

What we built

Spend Accounts are stored-value accounts that live next to the customer’s credit account. A customer can open one in seconds, name it, fund it, and start spending from it immediately with the same card.

• Instant account creation – customers open a Spend Account from the app in a few taps, with no additional underwriting required.
• Flexible funding – accounts can be funded via ACH bank transfer or debit card, with clear timelines for when funds become available to spend.
• Spend from balance – purchases are authorized in real time against the account balance, so customers can never overdraw.
• Rewards continuity – spending from a Spend Account still earns rewards, so customers are not penalized for choosing to spend their own money.
• Unified visibility – transactions, balances, and history for credit and Spend Accounts appear in one place, in one app.

How it works

The customer flow

A customer opens the app, creates a Spend Account, and links a funding source. Once funds land, the account becomes spendable. At the point of sale, the customer uses the same physical or digital card they already carry – the platform decides, based on the customer’s settings and available balances, which account the transaction should draw from.

Key product decisions

• One card, many accounts. We deliberately avoided issuing a separate card per account. The single-card experience keeps the wallet simple, but it pushed real complexity into the authorization logic – every transaction needs a routing decision in milliseconds.
• No overdraft, by design. If the balance does not cover a purchase, we decline (or route to credit, if the customer allows it). This protects customers from fees and protects the business from negative balances.
• Funding transparency. ACH is slow and customers hate ambiguity, so we invested heavily in communicating exactly when money would be available – a small detail that reduced funding-related support contacts by roughly 30%.

Under the hood (for the engineers)

• Real-time ledger. Every Spend Account sits on a double-entry ledger that records funding events, authorization holds, settlements, refunds, and reversals. Available balance = settled balance minus active holds – computed at authorization time.
• Authorization path. When a card authorization arrives on the network rails, the decision engine has a strict latency budget (well under a second) to identify the customer, select the funding account, check the balance, apply risk rules, and respond with an approve or decline.
• Holds and settlement. Authorizations create holds that later settle, expire, or reverse. Getting the hold lifecycle right (partial captures, tips, incremental auths at hotels and gas stations) was one of the hardest correctness problems in the project.
• Funding rails. ACH pull for bank funding (with return-risk handling for a window after the transfer) and debit card funding for instant availability, each with their own risk and cost trade-offs.

My role

• Owned the product definition end to end: problem framing, requirements, edge-case specification (holds, refunds, ACH returns), and launch criteria.
• Worked daily with engineering on the ledger and authorization design, translating payments-network behavior into product rules the team could implement and test.
• Partnered with design on the account creation and funding flows, and with compliance/legal on stored-value and disclosure requirements.
• Defined the success metrics and reporting for the launch, working with a cross-functional team of 12 engineers, designers, and QA across web, iOS, and Android through a phased delivery of roughly a year.

Challenges and trade-offs

• Correctness over speed to market. A ledger that is wrong even 0.01% of the time destroys trust. We invested in reconciliation and invariant checks before scaling up.
• Auth routing complexity. The “one card, many accounts” decision meant handling messy real-world authorization patterns (incremental auths, offline transactions, forced posts) without ever double-spending a balance.
• ACH risk vs. availability. Making funds available faster increases return risk; making customers wait hurts the experience. We tuned availability windows based on account tenure and risk signals.

Results

• About 25% of monthly active customers opened at least one Spend Account within six months of full rollout.
• Funding and spend volume grew steadily, with double-digit month-over-month growth across the first two quarters.
• Customers with an active Spend Account transacted roughly 15% more often per month and retained better than comparable non-adopters.
• Funding-related support contacts dropped by about 30% after the availability-transparency improvements.

What I learned

Spend Accounts taught me that in payments, the product spec is the edge cases. The happy path was designed in a week; the next months were spent making holds, returns, refunds, and routing behave correctly in every combination. It also reinforced a core PM lesson: transparency (about money movement timing) is a feature, and often a cheaper and more effective one than speed itself.