Why a Working Prototype Beats a Pitch Deck With Processor and Bank APIs

A working prototype beats a pitch deck because the review on the other side of the table was built specifically to discount the deck. Every bank and card network due diligence process that a fintech has to pass is designed to check whether claims match reality. A prototype is the one artifact that actually answers that question.

The federal banking agencies, the Federal Reserve, the FDIC, and the OCC, published joint interagency guidance in 2023 on how banks should manage risk in third-party relationships. It explicitly names fintech partnerships as squarely in scope. The guidance lays out what due diligence should cover before a bank enters a relationship, and one category is almost uncomfortably direct about what it is checking for.

The guidance tells banks to check your claims against reality

Under the “Business Experience” factor, the interagency guidance states that a review of a third party’s “websites, marketing materials, and other information related to banking products or services may help determine if statements and assertions accurately represent the activities and capabilities of the third party.” That sentence describes exactly what a pitch deck is. It also explains why a bank’s risk team is trained to treat a deck as a claim to verify, not evidence to accept.

A separate section, “Management of Information Systems,” goes further. It states that when technology is a major component of the relationship, an effective practice is for the bank to review both its own and the third party’s information systems together. The goal is identifying interoperability issues and gaps in service-level expectations before they become a production problem. A narrative description cannot satisfy that review. It requires something that actually runs against real systems, which a pitch deck, by definition, does not.

What Visa’s own onboarding review inspects directly

The same pattern holds on the card network side. Visa’s Payment Facilitator and Marketplace Risk Guide requires an acquirer to complete a due diligence review before it may contract with and register a prospective payment facilitator or marketplace. That review is not limited to paperwork. It explicitly requires an onsite inspection of the prospective payment facilitator’s business operations and its operational risk policies, procedures, and controls. Underwriting, risk monitoring, and data security are named specifically.

An onsite inspection of operational controls is a review of what a business actually does, not what it says it will do. A team that has built a working integration against a processor’s sandbox, including real underwriting data flows, real dispute and risk-monitoring webhooks, and real data-handling controls, walks into that inspection with something to show. A team with only a roadmap and a deck is asking the inspector to take the roadmap on faith, at the exact moment the inspection exists to avoid doing that.

What a sandbox integration actually forces a team to solve

The value of building against a real processor or bank sandbox API goes beyond having something to demonstrate. It forces a team to solve problems a slide never exposes. Authentication and credential rotation have to actually work, not just appear in an architecture diagram. Rate limits have to be handled gracefully. That means the team has already hit them in testing rather than discovering them in production during a launch week. Idempotency keys have to be implemented correctly so a retried request does not create a duplicate charge or a duplicate ledger entry, a detail that only becomes visible once a real API call fails and gets retried.

Webhook signature verification has to be implemented and tested against the processor’s actual signing scheme. It cannot just be assumed to work because the documentation describes the format. Settlement file formats, often the least glamorous and most failure-prone part of a payments integration, have to be parsed and reconciled against real test data. That process routinely surfaces edge cases, partial batches, currency rounding, timing mismatches, that a product requirements document never anticipates. Each of these is a place where a team’s actual competence shows up or does not. None of them are visible in a pitch deck no matter how detailed the architecture slide looks.

A concrete example: the settlement file that never matches on the first try

Consider a team integrating with a processor’s sandbox for the first time, building out daily settlement reconciliation. The processor’s documentation describes the settlement file format in a few paragraphs and a sample row. The first real file the sandbox produces rarely matches that sample exactly. A batch gets split across two files because of a volume threshold nobody mentioned in the docs. A refund nets against the original transaction in one file and appears as a separate line in another. A currency conversion rounds differently than the authorization amount implied it would.

None of this is a defect in the processor’s system. It is the ordinary texture of a real settlement process, the kind of detail that exists in every processor’s actual file format and in none of its marketing copy. A team that has reconciled three weeks of real sandbox settlement files against its own ledger has already found and fixed these mismatches. A team that described its planned reconciliation logic in a deck has not, and will find them for the first time during a live settlement run, with real money and a live sponsor bank relationship on the line instead of a sandbox account.

Why this changes the conversation with a bank or sponsor

A founder presenting a deck is asking a bank’s risk and compliance team to extend trust based on a narrative. A founder presenting a working prototype against the bank’s or processor’s own sandbox is handing that team something it can actually evaluate against its own due diligence checklist: the business experience review, the information systems review, and the operational inspection, all at once. That is a fundamentally different conversation, because the evidence being offered matches the shape of the question being asked.

This matters most at exactly the moment a fintech most wants to move fast. The first conversation with a sponsor bank or acquirer tempts a team to polish the pitch rather than build the integration first. The guidance both sides of that conversation operate under says the opposite. The bank is going to check the claims against reality either way. The only real choice a fintech has is whether that check happens during a sandbox-backed conversation it controls, or during a due diligence review later that it does not.

The scrutiny does not stop once the relationship starts

A working integration is not just the easier way to get past the first conversation. The interagency guidance’s own “Ongoing Monitoring” section makes clear the review never really ends. Banks are directed to confirm, throughout the life of a third-party relationship, the quality and sustainability of the fintech’s controls and its ability to meet its contractual obligations. Typical monitoring includes periodic review of performance reports, regular meetings to discuss operational issues, and in some cases direct testing of the fintech’s own controls, with more frequent and comprehensive monitoring expected for higher-risk activities.

A fintech that talked its way past onboarding with a strong narrative and a thin integration does not get to stop there. It faces the same reality check on a recurring basis, except now with real transaction volume and a live relationship at stake if the gap between the pitch and the system becomes visible. A fintech that proved its integration against the real sandbox before the relationship even started walks into every subsequent review with the same evidence it had on day one: a system that actually does what it was represented to do, because it was built and tested that way from the beginning rather than described that way under time pressure.

Building the prototype so it actually proves what it needs to

Not every prototype earns this benefit automatically. A demo that only exercises the easy path, a successful authorization with no decline, no retry, and no edge case, proves far less than one built to survive the failure modes a real integration will hit. The prototype that actually moves a due diligence conversation forward handles a declined authorization correctly. It demonstrates a retried request does not double-charge. It shows a reconciled settlement file rather than just an API response in a terminal window.

Building that version takes real engineering discipline against the processor’s actual sandbox environment, not a mocked API that returns whatever the demo needs it to return. The sandbox is where the painful discoveries happen: rate limits, authentication quirks, and settlement timing among them. A team that has already worked through those discoveries in a controlled environment is the team that looks competent in front of a bank’s technical reviewer. It is not the team explaining why production behaves differently than the deck promised.

This is exactly the work a disciplined POC development engagement is built to produce. A prototype built against real sandbox constraints from day one is worth far more than a mockup dressed up to look finished. The integration patterns that survive that process, idempotency, webhook verification, settlement reconciliation, become the foundation for the broader product development work that follows once the bank relationship is actually in place. The payment gateway and API integrations built during the prototype phase are not throwaway code meant to be replaced later. Built correctly against the real sandbox the first time, they are the production integration, proven before the relationship that depends on them ever had to take a claim on faith.

Frequently Asked Questions

What does a bank’s due diligence review actually check before partnering with a fintech?

The federal banking agencies’ interagency guidance on third-party relationships directs banks to evaluate a fintech partner’s business experience, management of information systems, and risk management, including reviewing the fintech’s own marketing materials and websites to determine whether statements and assertions accurately represent its actual activities and capabilities.

Does Visa require an onsite inspection before approving a new payment facilitator?

Yes. Visa’s Payment Facilitator and Marketplace Risk Guide requires an acquirer’s due diligence review to include an onsite inspection of the prospective payment facilitator’s business operations and operational risk policies, procedures, and controls, covering underwriting, risk monitoring, and data security, before the acquirer may contract with and register it.

Why does building against a sandbox API matter more than describing the integration in a pitch deck?

A sandbox integration forces a team to handle the real technical constraints of a processor or bank API, including authentication, rate limits, idempotency, webhook signature verification, and settlement file formats, that a narrative description cannot expose. A working prototype demonstrates the team has already solved those problems rather than asserting that it can.

Sources: Interagency Guidance on Third-Party Relationships: Risk Management and Visa Payment Facilitator and Marketplace Risk Guide.