About Fluz

Fluz is a New York fintech operating three business lines under a sponsor-bank model: a consumer rewards platform, a corporate card and spend management product used by 9,000+ businesses, and Fluz Platform — embedded payments infrastructure that lets other companies build card issuing, wallets, payouts, gift cards and rewards into their own products, under their own brand. The platform has processed over $5B for clients across political giving, legal settlements, gaming, e-commerce, gig marketplaces, loyalty and crypto.

The role

Every Platform deal has a technical scoping step between “we have a deal” and “engineering starts.” This role owns it.

The artifact at the centre of it is the Fluz Solution Design — the document that tells a client what they’re buying, how money actually moves, what they have to build, what the limits are, what will bite them in month two, and what they still have to decide. It is read by two people at once: the client’s business lead, who reads the overview and the open items, and the client’s engineering lead, who lives in the implementation steps and follows the links straight into our API docs. You write for both.

That document is the deliverable. The rest of the job is what makes it credible: being in the room from discovery, knowing the product cold, and staying attached until money moves.

What you’ll own

The solution design for every Platform client. Business overview, CIP (KYC/KYB), use cases, funds flows, money movement, spend account configuration, transaction limits, implementation steps, dependencies, considerations and open items. Delivered in the house format, on a predictable clock after close.

• Reconcile the sources before you write. The proposal deck, the call notes and the signed SOW will disagree, because they were written at different points in the sale. Commercial terms: the paper wins. Scope and product set: the most recent source wins. Anything about the client’s own business: their material wins over a funds flow narrative copied from another deal. Surface every conflict you resolve — don’t quietly pick one.
• Get the product facts right before you flag risk. A confident statement about the Fluz product that turns out to be wrong is the most expensive thing this seat can ship. It understates the product to a client who is buying it, and the platform contradicts it within weeks.
• Write flags as build tasks, not lectures. “Map retailers to the BIN that performs best” — not a warning about the client’s regulatory posture or how sophisticated their customers are. Flags about Fluz’s platform behaviour survive review; flags about the client’s business get cut.
• Find what breaks in month two. Where does money leave the account earlier than they expect? What have they assumed is recoverable that isn’t? Which limit forces a workaround? The standing checklist is a floor. The best flag in any of these documents is the one specific to that client’s program.

Technical discovery and the pre-sales bar. Attach at qualification, not after signature. Run technical discovery with the client’s CTO or head of product, scope proofs of concept and sandbox evaluations against their real objectives, and answer architecture, API, data, IT operations and security questions with authority. You are the technical lead on strategic client relationships, and the technical conscience of the deal — including saying, early and in writing, when a deal is being oversold.

Complete command of the product surface. Card issuing (commercial cards, low- and high-risk MCCs, non-resident beneficial owners), open- and closed-loop gift cards and breakage, wallets and virtual accounts, money movement across ACH, OCT, AFT, RTP, FedNow and wires, CIP/KYB and KYC autofill, embedded card reveal and push provisioning, webhooks, scopes, limits — plus the roadmap and an honest read on where we win and lose against alternatives.

The developer documentation. docs.fluz.app is where the client’s engineers live after the call ends. You own whether it answers their questions: verified links in every design, gaps reported with the deal that exposed them, and a working relationship with the engineers who maintain it.

Enablement and the product feedback loop. Train the AEs and Implementation Managers on what we can and can’t do. Build and run demos, webinars and internal sessions. Carry gaps in product/market fit back to Product and Engineering with the deal evidence attached, so investment decisions have a real signal behind them rather than an anecdote.

Where you sit in the account lifecycle

The Account Executive owns the account from first contact to signature. The Implementation Manager owns it from signature to live and ramping. The Technical Account Manager owns it after that.

You cut across all three. You attach during qualification, own the technical track through close, and the solution design is part of the handoff brief that crosses from Sales to Implementation. You stay attached through first transaction. After that you’re a called resource, not the owner.

What you’re measured on

• Share of signed Platform volume that actually goes live, and the time it takes. Signed is not revenue.
• Cycle time from close to solution design delivered.
• Implementation rework traceable to a design error or omission. This is the quality bar for the seat.
• Technical win rate on deals you’re attached to, and the technical objections that keep recurring.
• Deflection: engineering questions the documentation answered without a human.

What we’re looking for

• 5+ years in solutions engineering, sales engineering, technical pre/post-sales, implementation or technical account management, including time selling to CTOs and heads of product.
• Payments or fintech depth. Card issuing, ACH and wires, KYC/KYB, interchange, and ideally life inside a program-manager or sponsor-bank model.
• Fluency with REST APIs, webhooks, authentication and scopes, and sandbox testing. You can read a client’s proposed integration and find the flaw in it.
• Genuine technical writing ability. This role is judged on documents as much as on meetings. If writing a precise, well-organised twenty-page technical document is not something you enjoy, this is the wrong seat.
• Funds flow diagramming. You can draw how money moves through a program — every account, every hop, every timing difference — and you keep the diagram current as scope grows. A design whose diagram predates half the products in it is not finished.
• Comfort treating compliance and bank approval as part of the deal rather than an obstacle to it. Bank approval is usually the long pole; you plan around it from the first call.
• Willingness to tell an internal stakeholder something they don’t want to hear, in writing, early.

Nice to have

• Working understanding of a modern issuer processor stack.
• Gift card economics — open-loop and closed-loop, breakage, distribution.
• Travel VCCs, merchant-of-record programs, or stablecoin rails.

How this team works

1. Nothing counts until money moves. Signatures and go-lives are not the outcome.
2. Escalate with a recommendation, never just forward.
3. If it isn’t in the notes, it didn’t happen. The next person works from what you wrote.
4. Get the product facts right, then flag the risk.
5. Compliance and banking are part of the deal, not an obstacle to it.