AFEX Integrated Solutions Pitch Deck Breakdown: The Slide

What this deck actually is

Fifteen slides, 960 x 540 points, built in Microsoft PowerPoint 2013 and printed to PDF on 21 September 2020 . The file is 1.0 MB. It is not an investor deck. It is an enterprise sales and partnership deck for AFEX Integrated Solutions — the API product line of Associated Foreign Exchange, a cross-border payments and FX risk-management firm founded in 1979 and headquartered in California. The cover carries one name: Matt Teumer, Enterprise Sales Director , with a mobile number and an email address.

That distinction matters for how you read every page that follows. Nobody is being asked to buy equity. The reader is a CTO, a head of finance, or a platform founder who is deciding whether to build cross-border payment rails themselves or rent someone else's. The deck's entire job is to answer one question — should we integrate this instead of building it? — and to make the next meeting easy to say yes to.

On the merits of that job, this is a materially better document than most decks we tear down . It has two named, quoted, on-the-record customers. It has a specific implementation process with five labelled phases. It has an API capability list written in the language an integrating engineer actually thinks in. Those three things put it ahead of the median B2B deck by a distance.

And it still fails at the moment of truth, in four specific and fixable ways: a slide titled "AFEX in numbers" that contains no numbers, two case studies with no measured results, a fifteen-slide sales document with no pricing and no commercial terms of any kind, and a 2020 deck stamped with a 2019 copyright line on five of its pages.

Slide 4 is titled "AFEX in numbers" and has no numbers

This is the single clearest miss in the file, and it is worth dwelling on because it is so easy to fix.

Slide 4 carries the headline "AFEX IN NUMBERS" . What sits beneath it is three statements:

"Strategic partnerships in EMEA, APAC, and the Americas " · "Trusted business partner for foreign exchange solutions since 1979 " · " Licensed and regulated in every jurisdiction where we operate"

Three regions, one year, and a compliance assertion. A slide promising quantification delivers a founding date and two adjectives. Nothing on it can be counted, benchmarked, or checked.

The remarkable part is that AFEX had the numbers and put them on the previous slide instead. Slide 3 states the company trades approximately $30 billion in foreign exchange each year for 35,000 commercial and private clients , operating 24/7. Slide 7 states more than 100 currencies to 180 different countries . Slide 8 gives eGlobalfares 30+ currencies, clients in 80+ countries . Slide 11 gives PayRecs 36 currencies .

So the deck contains: $30bn annual volume, 35,000 clients, 100+ currencies, 180 countries, 41 years of operating history. That is a genuinely strong scale story — and the slide built to tell it tells nothing. Every one of those figures should be on slide 4, in large type, and slide 3's prose paragraph should be the thing that gets cut. As shipped, the reader encounters the scale numbers buried in a body-copy paragraph on a slide titled "About us", then turns to a page announcing numbers and finds none.

Rule this illustrates: a slide's title is a promise. If the headline says "in numbers", the body must be numbers, at a size that can be read from the back of a room.

Two case studies, zero measured results

Slides 8 and 11 are the strongest pages in the deck and the biggest wasted opportunity in it.

eGlobalfares (slide 8) is a travel-technology company founded in 2004, serving corporate travel management companies and leisure agents across 80+ countries. The deck lays out its challenges cleanly — incoming and outgoing payments in 30+ currencies, high payment volumes needing automated reconciliation, clients paying in local currency against supplier currencies, global offices to fund — and then the AFEX solution: real-time conversion at live rates, automated reconciliation against invoices, scheduled outgoing payments, and balance visibility with instant inter-office transfers. It closes with a named quote from Dave Rifkin, CEO .

PayRecs (slide 11) is a startup founded by two FX and fintech professionals building "intelligent invoicing" for mid-market exporters. Its wish list is stated, the partnership solution is described across four bullets, and Jon Dobson, CEO is quoted: "Within five minutes of talking with AFEX, we thought 'this is exactly what we need.'"

Named companies. Named executives. Attributable quotes. Real, checkable customers who agreed to be used as references. This is expensive social proof, and most vendors never get it.

Then look at the "Results:" band at the bottom of both slides — the place where a case study either lands or evaporates.

eGlobalfares results: "Saves time and money for eGlobalfares and their clients" / "Automated reconciliation and reporting function reduces errors" / "Greater visibility of processes adding operational efficiency and scalability."

PayRecs results: "Immediate proof of concept, giving sales team momentum" / "Automated reconciliation and reporting function reduces errors" / "Greater visibility of processes adding operational efficiency and scalability."

Two of the three results are copied verbatim between the two case studies. Word for word, in the same order. Whatever was specific about either engagement has been sanded into a shared template.

And not one of the six results contains a measurement. How much time? How much money? Errors reduced from what to what? Reconciliation cycle from how many days to how many hours? Payment failure rate before and after? Time from contract to first live payment? Volume processed since go-live? The customers were willing to be named and quoted — which means they were almost certainly willing to be asked "what did this actually save you?"

A single sentence — "reconciliation that took two staff three days a month now runs automatically" — would do more work than all six of these lines combined. As written, the results bands are the part of the deck a buyer skims, because they say nothing a buyer could not have guessed before opening the file.

Fifteen slides, no price, no terms, no commercials

This is a sales deck for a product whose entire value proposition is economic, and it contains no commercial information at all .

There is no pricing. No FX spread or margin. No implementation fee. No per-transaction cost. No minimum volume. No contract length. No revenue-share percentage. No indication of what "competitive profit sharing" on slide 14 means in basis points. No worked example of a $100,000 payment showing what the client pays and what the client earns.

The deck instead makes economic claims in adjectives. Slide 14 promises "competitive rates & reduced fees" , "pricing transparency" , and "no intermediary fees" . Slide 7 promises "increased revenues" . Slide 10's partner model promises to "expand your service offering and revenue stream" .

"Pricing transparency" as a bullet point in a document with no prices is a hard sentence to write past. It is the deck's own standard, applied to everyone except the deck.

The counter-argument is that enterprise FX pricing is bespoke, volume-tiered, and negotiated — which is true, and which is exactly why the omission is a choice and not an accident. But bespoke pricing does not prevent a vendor from showing a structure : how pricing is arrived at, which variables move it, and one illustrative scenario. A partner deciding whether to embed a payments product needs to model their own margin before they will schedule the technical call. Without a single number, the deck cannot be forwarded internally to a finance stakeholder, and a deck that cannot be forwarded stalls in the inbox of the person who received it.

A 2020 deck with a 2019 copyright

Five slides — 3, 7, 8, 10 and 11 — carry the footer "© 2019 Associated Foreign Exchange, Inc. All rights reserved." The file was created on 21 September 2020 .

On its own, a stale copyright line is trivia. In context it is a dating signal: the substantive content pages were built in or before 2019 and re-sent in late 2020 without review. The pages that carry no footer — the agenda, the section dividers, the process slide, the closing pages — are the ones most likely to have been added later.

The reason this matters more than usual in this specific deck is the date. A cross-border payments deck circulated in September 2020 says nothing whatsoever about 2020. There is no mention of the pandemic's effect on payment volumes, on the travel sector — which is the industry of the deck's own flagship case study, eGlobalfares , a travel-payments company — or on FX volatility during the most turbulent currency year in a decade. A buyer reading this in Q4 2020 is living inside a market event the deck does not acknowledge exists.

That silence also affects the case studies. If eGlobalfares' travel volumes had collapsed and recovered on the AFEX rails, that is a resilience story worth more than every adjective on slide 14. If they hadn't, the deck should not be leading with a travel customer without a word about the year travel had.

The structure: 8 slides of capability, 2 of proof, 1 of process

Slide 2 is an eight-item agenda — About AFEX, Integrated Solutions, Direct API, eGlobalfares, Partner API, PayRecs, Our process, Summary, Resources — and the deck follows it faithfully. That discipline is worth crediting; the reader always knows where they are.

Slides 3-4: company background · Slides 5-7: Direct API — one overview, one divider, one full page of benefits · Slide 8: case study · Slides 9-10: Partner API — one overview with a flow diagram, one full page of benefits · Slide 11: case study · Slide 12: integration process · Slides 13-14: API capability list and a combined benefits/use-cases page · Slide 15: resources

That is roughly eight slides of capability and benefit assertion against two slides of customer evidence — a 4:1 ratio of claims to proof, in a category where the buyer's real question is not "can this be done" but "has this been done reliably for someone like me".

The repetition compounds it. Slide 7 (Direct API benefits) and slide 10 (Partner API benefits) both list "account security — safeguarded data encryption authenticates all requests with unique API keys". Both list global reach. Both list operational efficiency and automated beneficiary validation. Then slide 14, "API Benefits and Use Cases", lists many of the same points a third time under new headings, mixing what are plainly benefits ("increased revenue stream", "price improvement", "process improvement") under a title that promises use cases and then supplies none. There is not one named use case on the use-cases slide.

Compressing slides 7, 10 and 14 into a single differentiated comparison — here is what Direct API gives you, here is what Partner API gives you, here is how to tell which one you are — would free three slides. Those three slides are exactly where the missing pricing structure, the missing measured results, and a missing technical page belong.

The two products are never disambiguated for the reader

Slide 5 draws the distinction correctly and in one sentence each: Direct API connects your own ecosystem or ERP to AFEX's payment and risk tools — you are the payer. Partner API lets you offer payment services to your customers under your interface — you are the platform, and AFEX handles onboarding and KYC behind you. Slide 9 adds a flow diagram showing Partner/AFEX → Client → Client's Client/Vendor.

These are two fundamentally different commercial relationships with different risk profiles, different regulatory exposure, different integration scope and different economics. The deck describes both and then never tells the reader how to choose . There is no decision rule, no "if you are X, start here", no comparison table, no indication of which is faster to launch or which requires more compliance work on the partner's side.

A prospect who does not immediately self-identify has to sit through both tracks, and half the deck is addressed to someone else. One two-column slide — Direct if you are paying your own suppliers; Partner if your customers are paying theirs — would let every reader skip to their own half and arrive at the case study that applies to them.

What the deck gets right

The process slide is excellent. Slide 12 breaks integration into five named phases — Discover, Initiate, Define, Execute, Support — with three to four concrete activities under each: scope and business case; compliance, risk, credit and operations assessment; functional design, API flow creation, test plan and beta; end-to-end test environment, test case execution, evaluation and iteration; then post-go-live account management and maintenance. This is the slide that de-risks the purchase. It tells a technical buyer that AFEX has done this often enough to have named the stages, and it names the internal teams the client will actually meet. Most vendor decks replace this with the word "seamless".

The capability list speaks engineer. Slide 13 organises the API into five domains — onboarding, beneficiary management, risk management, payments, reference data — and the reference-data line ("we expose much of our metadata including details required for beneficiary set-up, limits, rates, fees and supported currencies") is the kind of detail only someone who has integrated a payments API would think to include. It signals a real, documented product rather than a roadmap.

The regulatory pitch is the right pitch. "Instead of building your own global payments infrastructure, use ours" (slide 5) and "leverage our regulatory and compliance structures rather than building your own" (slide 14) correctly identify that the expensive part of cross-border payments is licensing and compliance, not code. For a fintech founder, that is the argument that actually lands.

The customers are real and named. Two companies, two CEOs, two attributable quotes. The evidence exists; it is only the measurement that is missing.

The close does not ask for anything

The final slide is titled "Resources" . It offers a URL (apisolutions.afex.com), a LinkedIn follow, a phone number and an email address.

The agenda on slide 2 promised a "Summary" before resources. There is no summary slide in the file. The deck ends on contact details without ever restating what the reader is being invited to do.

"Follow AFEX on LinkedIn" is a brand-awareness action sitting in the position where a sales deck should place its commitment ask. There is no proposed next step, no offer of a technical scoping call, no sandbox or documentation access, no timeline, no "here is what the first two weeks look like". Slide 12 already contains the answer — phase one is "Discover: determine scope, business case, proposal" — and the close never connects to it.

The fix is one line: "Next step: a 45-minute scoping call with our integration team to size your volumes and map your flows." A deck that names the next meeting gets the next meeting.

The five-slide rebuild

Everything above resolves into five specific edits, none of which requires new material AFEX does not already have:

Put the numbers on the numbers slide. $30bn traded annually, 35,000 clients, 100+ currencies, 180 countries, since 1979. Five figures, large type, on slide 4. Cut the prose paragraph on slide 3 that currently hides them. · Measure the case studies. Go back to eGlobalfares and PayRecs and ask for one hard number each — hours saved, error rate, days to go-live, volume processed. Delete the two boilerplate result lines that currently appear on both slides. · Show a pricing structure. Not a rate card — a model. What drives cost, what drives partner revenue share, and one worked example on a representative payment. · Add a Direct-vs-Partner decision slide and cut one of the three overlapping benefits pages to pay for it. · Replace "Resources" with a close. Restate the three strongest facts, name the next meeting, and keep the contact details underneath it.

The underlying business here is strong and the evidence is already in the room. This deck's failures are not failures of substance — they are failures of a sales document that lists what it can do more carefully than it proves what it has done, and then forgets to ask.