AFEX Integrated Solutions' 15-slide deck, built in PowerPoint 2013 and dated 21 September 2020, is an enterprise sales and partnership deck for the API arm of a 1979-founded cross-border payments firm trading roughly $30 billion a year for 35,000 clients. It does several things unusually well: a five-phase integration process with named internal teams, an API capability list written for engineers, and two case studies featuring real named companies and on-the-record CEO quotes. But the slide titled "AFEX in numbers" contains no numbers at all — the scale figures sit in body copy on other page…
Key takeaways
- A slide titled "AFEX in numbers" contains no numbers - only three regions, a founding year and a compliance assertion. The company's real figures ($30bn traded annually, 35,000 clients, 100+ currencies, 180 countries) are buried in body copy on other slides.
- Both case studies name real companies and quote named CEOs, but two of the three "Results" lines are copied word for word between them, and not one of the six results contains a measurement.
- Fifteen slides of a sales deck contain no pricing, no FX spread, no implementation fee, no revenue-share percentage and no contract terms - while slide 14 lists "pricing transparency" as a benefit.
- Five slides carry a "© 2019" footer in a file created 21 September 2020, and the deck says nothing about 2020's payment-volume disruption despite leading with a travel-sector case study.
- Direct API and Partner API are two different commercial relationships, described in full but never disambiguated - there is no decision rule telling a reader which one applies to them.
- Eight slides of capability and benefit assertion against two slides of customer proof, with the same security, reach and efficiency claims repeated across slides 7, 10 and 14.
- The five-phase integration process on slide 12 is the strongest page in the deck and the one that most de-risks the purchase - most vendors replace this with the word "seamless".
- The agenda promises a Summary that does not exist; the deck ends on a "Resources" page whose most prominent action is "Follow AFEX on LinkedIn" rather than a proposed next meeting.
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.
Frequently asked questions
- Is the AFEX Integrated Solutions deck an investor pitch deck?
- No. It is an enterprise sales and partnership deck for AFEX's API product line, presented by Enterprise Sales Director Matt Teumer. There is no funding ask, no cap table, no financial projection and no valuation. The reader is a prospective client or platform partner deciding whether to integrate AFEX's payment rails rather than build their own, so the deck should be judged as a B2B sales document - which is why the absence of pricing and measured customer outcomes matters more here than the absence of investor artefacts.
- What is the biggest single flaw in the AFEX deck?
- Slide 4 is titled "AFEX in numbers" and contains no numbers - just three regions, the year 1979 and a licensing statement. The company's genuinely strong scale figures appear elsewhere: approximately $30 billion in FX traded annually for 35,000 clients (slide 3), and payments in more than 100 currencies to 180 countries (slide 7). The quantification exists; it is simply on the wrong pages, so the slide built to establish credibility at a glance establishes nothing.
- What is the difference between AFEX Direct API and Partner API?
- Direct API connects a company's own ecosystem or ERP to AFEX's payment and risk-management tools - the integrating company is the payer, using the API for its own high-volume cross-border payments. Partner API is white-label: the integrating platform offers payment services to its own customers under its own interface, with AFEX handling onboarding and KYC behind the scenes. The deck describes both clearly but never gives the reader a rule for choosing, so half the document is addressed to someone else no matter who is reading it.
- Why are the case studies on slides 8 and 11 criticised if they name real customers?
- Because named customers and attributable CEO quotes are the expensive part of a case study, and AFEX obtained both from eGlobalfares and PayRecs - then wasted them. The "Results" band on each slide offers unmeasured phrases like "saves time and money" and "reduces errors", and two of the three lines are identical between the two case studies. Customers willing to be quoted are almost always willing to supply one hard number, and one measured outcome would outperform all six generic lines.
- Should a B2B sales deck include pricing?
- It should include pricing structure even when the final price is negotiated. Enterprise FX pricing is legitimately volume-tiered and bespoke, but a partner cannot model their own margin - or forward the deck to a finance stakeholder - without knowing which variables move cost and roughly what a representative transaction looks like. Showing how pricing is arrived at, plus one worked example, keeps the negotiation open while making the deck usable internally by the buyer.
- What does the deck get right?
- Four things. The five-phase integration process on slide 12 (Discover, Initiate, Define, Execute, Support) with named internal teams and concrete activities is genuinely de-risking. The API capability list on slide 13 is written in the language an integrating engineer uses, including exposed reference metadata. The core argument - that the expensive part of cross-border payments is licensing and compliance, not code, so rent ours - is the correct argument for the audience. And the two case studies feature real, named, quotable customers.
