If you look at most of our customers from the outside, their problem sounds simple: they need to move money in and out of Latin America.

In reality, the pattern is almost always the same. A business based outside the region is growing in Brazil, Mexico, Colombia, or elsewhere in LATAM. They’ve stitched together a few partial solutions—or have no local setup at all—and they’re hitting a wall. They need to collect money locally, move it across borders, and manage balances across entities, without rebuilding an entire banking and compliance stack country by country.

That’s where alfred sits: in the messy middle between global businesses, local payment rails, banks, and FX rules. The product team’s job is to turn that mess into something that feels like a single, predictable system.

This is how we do it.

From “we see an opportunity” to “this is a product”

Historically, our process started top‑down. We’d see a specific opportunity—say, enabling local collections in a new market for a particular kind of customer—and scope out what it would take to service that use case end‑to‑end. From there, we distilled those needs into requirements we’d have to build inside alfred: which accounts, which rails, what compliance checks, what reporting, how FX should behave.

That’s now evolving into a more modular approach.

Instead of building one‑off, corridor‑specific solutions, we’re building a set of reusable capabilities—a kind of menu of modules—that we can compose into solutions for different customers and partners. Think of things like:

• Local collection accounts in a given market
• Payout over a specific rail (Pix, SPEI, Bre‑B, local ACH variants)
• Cross‑border settlement via USDC
• Virtual accounts and statements
• Specific KYC / compliance flows

Product’s day‑to‑day work is defining and refining those modules, then working with go‑to‑market and partners to assemble them into concrete solutions for particular use cases.

How ideas actually move through the company

New product work can start in a few places, but often it begins with the go‑to‑market team. They’re closest to customers and prospects, so they hear the raw pain: “We’re trying to do X in Mexico and keep getting stuck on Y,” or “Our current provider can’t support this particular FX or compliance pattern in Brazil.”

Product comes in to translate that into something we can build.

We sit down with GTM to understand the use case and constraints, then start shaping it into actual features and modules. That usually means:

• Defining what we’re really solving for: collections, payouts, balances, FX, reporting, or some mix.
• Deciding which of our existing modules we can reuse and which ones we need to create or extend.
• Writing down what the feature needs to do—not just for one client, but in a way that can generalize.

From there, we pull in finance and operations. They help answer questions like: how should this behave on our internal ledgers, what does this mean for treasury flows, what kind of controls and reconciliations do we need, what’s acceptable from a risk point of view?

Once there’s alignment, product turns this into a Product Requirements Document (PRD). The PRD isn’t a formality; it’s the contract for the build. It spells out:

• What problem we’re solving
• Who we’re solving it for
• How it should work, at a functional level
• What it needs to integrate with—internally and with partners
• What “good” looks like in terms of adoption and usage

Engineering and development then take that PRD and turn it into running code. When a first version is ready, it moves through quality assurance, both on the technical side and from the perspective of “does this actually match what we set out to build?” Only after that do we loop back to the sales and GTM teams so they can start offering it to the right partners.

It sounds linear on paper; in practice, there’s a lot of back‑and‑forth. But the backbone is always the same: cross‑functional alignment → clear written spec → build → test → ship → validate with real users.

Prioritization: opportunity and volume, not just elegance

In a region like LATAM, there’s no shortage of things we could build. The harder question is what we should build first.

The head of product thinks about prioritization in terms of opportunity and volume. If a use case unlocks meaningful, sustained money movement for customers, it moves up the list. That might be because:

• It opens a new market (for example, bringing a country online for collections).
• It deepens a corridor that already has strong demand.
• It significantly reduces friction or failure rates in an existing high‑volume flow.

Of course, there are other factors—technical risk, regulatory timelines, partner readiness—but potential volume is the forcing function. That’s part of being infrastructure: we’re here to move real money, not just to ship features.

Building with real markets, not theoretical ones

A lot of product work at alfred is shaped by very non‑software realities.

Sometimes those realities are technical. Brazil’s Pix system is a sophisticated, always‑on instant payments network with rich APIs and data. Building on top of Pix feels like building on a modern, digital rail.

Other markets are not like that yet. In places like Peru, Bolivia, or the Dominican Republic, we run into networks and banking systems with more limited capabilities: fewer real‑time options, less consistent data, more manual steps. The product we can build there has to reflect what’s actually possible, not what would be ideal.

Sometimes the realities are regulatory or compliance‑driven. Each country has its own rules for how you identify individuals and businesses, how you connect bank accounts, how FX is documented, how tax references need to be attached to payments. Designing a unified product while respecting those local rules is a constant constraint. You can’t just “standardize” away KYC or FX controls.

And sometimes the realities are cultural and language‑driven. In another product context, our head of product described building an interface for WorldCoin in the Philippines. The first version was built using automated translation tools; it worked mechanically but felt off. Only after working with a local partner and account manager—someone who actually uses the language and understands the context—did the team realize how much the wording needed to change. The lesson shows up in LATAM too: local partners and customers are critical for getting the details right.

How much complexity we expose (and how much we hide)

A recurring design question for us is what to abstract behind the API and what to surface.

On one hand, our job is to hide a lot of complexity. Customers shouldn’t have to think about which local ACH variant is being used, how we’re routing through providers, or how we deal with specific banks’ quirks. They want local rails, local accounts, and cross‑border movement that behaves predictably.

On the other hand, we can’t hide everything. Teams running treasury and finance operations need visibility into how money moves: when a payment is in flight, what FX rate was applied, whether a local regulator might delay a transfer, how to reconcile what they see in alfred with what’s in their ERP and bank statements.

The product and API design work lives in that tension. We try to give customers the visibility they need to operate—statuses, timestamps, references, balances, FX information—without turning the interface into a mirror of every internal system and bank we deal with. It’s an ongoing calibration.

Knowing whether a release worked

Shipping a feature is not the finish line. We only know a release worked when it behaves the right way for customers and for us.

On the customer side, we look for adoption and actual use: how many partners have integrated the new capability, how many end users are touching it, how much money is moving through it, what completion rates look like on specific processes (for example, collections via virtual accounts).

On our side, we care whether the feature solves the problem it set out to address. That circles back to how clear the original problem statement was. If the PRD was precise and we can map behavior back to that statement, we can tell if we actually moved the needle.

User testing and feedback are a big piece of this. After launch, product spends time with partners and end users to see how the feature is working in real workflows. We listen for friction points we didn’t anticipate and for places where our assumptions about behavior were wrong. That feedback drives iteration, and sometimes it forces us to rethink a piece of the solution entirely.

Where we’re taking the product next

Looking six to twelve months out, a big focus for the product team is deepening what we can offer around balances and treasury for enterprises and financial institutions.

Practically, that means expanding how account structures work, improving how balances can be viewed and controlled across markets, and making it easier for sophisticated customers to run real treasury operations on top of alfred. It also means raising the bar on performance and reliability to match what bigger, more regulated players expect when they run due diligence on an infrastructure provider.

Underneath that, the product philosophy stays the same: build modular capabilities we can recombine; respect local technical and regulatory realities; be clear about where the complexity lives and how much of it we expose; and measure success in real usage and real money moved.

In a region where currencies, networks, and rules don’t always behave, there’s no such thing as a perfect product plan. What we can do is build a product development process that’s grounded in the actual problems customers face, the constraints of the markets we operate in, and a clear view of what “good” looks like when money is moving through alfred.