When people hear fintech PM, they picture someone shipping a consumer app. A Brex. A Mercury. A Wise. That is one job.

There is another job, less visible, that I have been doing for the past five years: building the platform a bank uses to be a fintech.

It looks like the same industry. It is a different muscle.

The customer is the bank

A consumer-fintech PM optimizes for end-user delight. Time-to-onboard, friction in the flow, NPS after first transaction. The user’s pain is the brief.

A vendor PM optimizes for the bank’s trust. The compliance team’s trust first. Then the regulator’s. Then the bank’s ops team’s. Then, somewhere down the line, the end user. That re-ordering changes the entire shape of the job. Discovery becomes interviews with risk officers and oversight examiners, not users at coffee shops. The North Star metric is rarely DAU. It is usually time-to-regulator-sign-off on a new program.

A specific moment, from a sponsor-bank compliance review of a new feature: the compliance lead asked one question. If the system fails open, what happens to the customers we already approved? I did not have an answer prepared. I had a feature spec. The compliance lead was asking about something that was not in the spec at all, the failure mode. We rebuilt the spec around that question. The feature was approved a month later.

Consumer-fintech PMs do not usually rebuild specs around the failure-mode question. They build specs around the happy path and let edge cases become tickets. In vendor banking, the failure mode is the spec. The happy path is the example.

The currency is auditability

Consumer fintech moves on speed. Vendor banking moves on legibility.

Every decision a vendor PM makes has to be defensible six months later in a regulator’s review. Why did you allow this exception. Why did you cap that limit. Why did the compliance team see this transaction at this time. The PM artifact that matters most is not the prototype. It is the spec, the change log, the decision memo.

Paper trail as product. The product is not what runs in production. It is the trail of decisions that explains why what runs in production runs the way it does.

This sounds bureaucratic. In practice it is the opposite. A team that has the audit trail wired in moves faster on regulator interactions, because the answer to most regulator questions is already on a screen. A team that does not have it wired in moves slower over time. Every regulator email turns into a forensic exercise.

Roadmaps look different

Consumer-fintech roadmaps are features. Vendor-bank roadmaps are capabilities and jurisdictional coverage.

A typical quarter on the vendor side: extend the ledger for a new asset type. Ship a regulatory report. Certify a new payment rail in a second jurisdiction. Harden three integrations. Almost no new screens.

Most user-visible features sit on top of capabilities the bank already paid for, which means PM credit is harder to claim and easier to lose. The team that shipped the ledger primitive last year does not get credit for the program that launched on top of it this year. That is a real career-legibility problem on the vendor side, and one of the reasons most ambitious PMs default to consumer products.

The compounding

A consumer fintech ships features. Each one stands alone, earns its keep, decays.

A platform ships capabilities. A capability shipped well becomes the foundation for the next ten programs the bank runs on top of it. The work compounds.

Five years in, I can trace the line. The capability shipped in 2022 became the foundation for the program that shipped in 2024, which became the basis for the regulator approval we received in 2026. Consumer features rarely give you that. The compounding is what eventually makes vendor work emotionally satisfying, once you have enough years to see it.

That is the trade. You give up career legibility in the first three years. You compound in the next ten.

What a week actually looks like

Specific texture, since most descriptions of vendor PM work skip this.

Monday: regulator-facing memo for the next compliance review. Two hours, deeply careful, single document. The kind of writing where one sentence gets reread fifteen times before it is final.

Tuesday: sponsor-bank ops sync. Forty-five minutes. A lot of can the system tell us when X happens. The work that comes out of this meeting is rarely a feature. It is usually a query, an alert, or a clarification of what a column means.

Wednesday: internal architecture debate. Two hours, mostly about contract boundaries. What does the API promise. What does it not promise. Who is reading this promise. The PM job in this meeting is to keep the contract from drifting.

Thursday: customer-voice review. Tickets, complaints, friction points. The vendor PM’s version of this is heavily filtered through the bank’s ops team. The customer voice you are reading is third-hand by the time it reaches you.

Friday: writing. The memo, the spec, the decision log. The week’s decisions get committed to paper.

What is missing from this week, compared to a consumer PM’s: the design review, the user-research session, the growth experiment, the launch.

What is present that a consumer PM does not see: the regulator interaction, the compliance review, the contract drafting.

It is the same word, PM, pointing at very different jobs.

The cost

Two things, mostly.

Feedback loops are slow. Eighteen months from shipping a regulatory primitive to knowing whether it was right.

And career legibility. The market knows what a Stripe PM does. It is still figuring out what a vendor PM at a banking-platform company does. That is part of why I built this site.

Both jobs are good jobs. They are just not the same job.