Fiat On and Off-Ramps and Cross-Border Payments on Stellar

To bridge the world's financial infrastructure, Stellar makes it easy for regulated financial institutions to set up anchor services, which are fiat on/off ramps for the network. Anchors accept deposits and withdrawals via traditional rails, and convert them to and from digital currency. They also interoperate with one another — and with other Stellar-built applications — to empower users to transact across borders and across currencies.

Currently, there are two standard transaction flows Stellar anchors and applications rely on to interoperate with each other, and for each, there is a technical spec explaining how to set up and consume a set of uniform APIs:

• SEP-24 specifies how anchors interoperate with wallets to allow users to deposit and withdraw assets.
• SEP-31 specifies how anchors interoperate with other anchors to allow users to make bank-to-bank cross-border payments.
  

If you're building an application, you can think of these two different flows as creating two different experiences for your end users. With SEP-24, your users interact directly with the anchor service you’ve integrated when depositing or withdrawing funds. If a user sends a remittance payment to another user, for example, the receiver needs to actively withdraw their digital asset balance to end up with money in the bank or cash in hand.

With SEP-31, your users will only ever interact with your application when depositing or receiving funds. This is because the anchor services you have integrated communicate the necessary KYC/AML details directly, and execute the transaction on behalf of the users on the back-end, as seen in more traditional remittance or corporate payments.

If you're building on Stellar and want to take advantage of the worldwide network of anchors, you'll likely need to implement one or both of these standards. To help you understand which one applies to your use case, this post offers high-level explanations and points to relevant resources. Before we dig into details, here's a quick comparison to orient you:

Stellar Ecosystem Proposals are open specifications that define best practices for building a product or service on Stellar. Generally, they explain how companies building on Stellar set up infrastructure external to the network — including APIs and clients to consume them — to maximize interoperability with other network participants, and to facilitate compliance with local laws and regulations.

The two transaction-flow SEPs described below work in conjunction with a suite of SEPs that allow interested parties to publish and discover relevant information about one another, create authenticated user sessions, and share relevant data including KYC information when conducting transactions. The goal here is to give a high-level overview of the transaction SEPs, so we'll gloss over the supporting SEPs for now. You can read more about them in the Anchor Assets section of the docs.

SEP-24 defines interoperation between Stellar anchor services (i.e. fiat on/off-ramps) and user-facing applications and wallets. These integrations allow consumers to deposit and withdraw fiat currency using their interface of choice.

An anchor implements the server side of SEP-24 by setting up a transfer server offering a single set of endpoints that work with any compliant client, and publishes the location of that transfer server so that wallets can discover and integrate with their service. They also host a webapp that users interact with to input any data necessary to authorize a fiat deposit.

A wallet implements the client side of SEP-24 by creating a single client that can consume any compliant anchor's endpoints. The wallet initiates a deposit via API calls to an anchor's endpoints, and serves the anchor's webapp to the user via a popup or iframe to complete the transaction.

The goal of SEP-24 is to make it easy for wallets to incorporate anchor services into their products while still allowing anchors to interact with customers to collect KYC information and perform verification via SMS or email. Because a customer completes a deposit or withdrawal without ever leaving the wallet interface, the experience is not unlike using a traditional banking app.

For details on how to set up a SEP-24 integration, check out the Enable Deposits and Withdrawals section of our docs.

SEP-31 is a spec that allows anchors to interact with one another to build a rail between two regions so that one end user can send fiat from their bank account directly to another end user's bank account.

Unlike SEP-24, which allows any compliant wallet to discover and interact with any compliant anchor, SEP-31 requires anchors to create bilateral agreements in advance to interoperate with one another: when you build an SEP-31 integration, you identify the counterparties with whom you will transact, and log the addresses of their Stellar wallets.

To support SEP-31 transaction flows, an anchor sets up APIs in order to receive payments and a client that consumes other anchors' APIs in order to send payments. Once two anchors set up the server and corresponding client necessary to support the SEP-31 flow, a compliant bank-to-bank transaction follows a specific, uniform process: a sending anchor's client goes through a series of interactions with a receiving anchor's API endpoints to create an authenticated web session, pass customer information, and receive the green light before initiating a transaction.

The uniformity created by following SEP-31 makes it easy to incorporate additional counterparties to extend business into new regions, and because the client/server interactions happen in the background, the customer experience is seamless, and feels just like a traditional remittance payment. In fact, customers don't need to know the transaction is happening on the Stellar network at all.

For details on how to set up a SEP-31 integration, check out the Enable Cross-border Payments section of our docs.

To make integration easier, the Stellar Development Foundation offers an extendable django app called Polaris that allows anchors to run a web server supporting all the SEPs necessary for SEP-24 and SEP-31 interactions. It handles the majority of the business logic described in each SEP, and provides clear methods for developers to integrate their own customer registrations, banking connections, and KYC and transaction processing. That means anchors can focus on implementing the business- and country-related aspects of their products without having to spend much time defining how to connect the server to the Stellar Network.

Polaris is well-documented, easy to use, and jumpstarts deployment so an anchor can connect local rails to Stellar in weeks instead of months. For more, check out the How To Build an Anchor With Polaris video tutorial.

In addition, SDF offers a suite of validating tools anchors can use to check SEP-24 and SEP-31 setups, and tutorials that demonstrate how to create a Stellar wallet, and how to add SEP-24 functionality to it. We plan to continue to add tools and resources to make the client-side setup easier.