Here at Swan, we talk a lot about our core product features. For those who have somehow managed to get to this post without encountering them, they are: accounts, cards, and payments.
What do we mean exactly by ‘accounts’? I will quote our website itself:
“Hold, receive, and send money. Give your customers the accounts they need, and let Swan handle the onboarding and ID verification processes.”
But it’s more than just that. Accounts are the fundamental unit of what we do. And we don’t just create them for our partners’ customers to use…
The most commonly known use for embedded finance involves integrating banking features into our customers products, so that their customers can have access to accounts, cards, and payment capabilities.
Expensya’s partnership with Swan is a great example of this. They use our BaaS platform to issue debit cards to their customers, who then use them to pay for and manage business spend. Every Expensya customer gets a card, and thus, an account.
We like to talk about partners like Expensya and Pennylane because they are great companies, of course, but also because how they work with us is rather intuitive. They want to offer their customers banking products but can’t do it on their own because of regulatory and development constraints.
However, Swan is not just used in this way. We also power companies that wish to embed finance capabilities internally. These firms are keen to integrate powerful and more automated payment orchestration in their value chains.
Among our 80+ partners, there are a plethora of ways our partners deploy Swan’s products internally. Today, we will look at three fascinating use cases: B2B payment orchestration, factoring, and consumer payment collection.
Let’s go.
Embedded cards for B2B payment orchestration
Companies whose core business models rest on making purchases on behalf of consumers have found a strong fit with our offering. Namely, firms running online travel agencies (OTAs) and BNPL platforms have successfully implemented our banking features to improve business operations and increase revenues.
For OTAs, they harness the power of Swan’s BaaS platform to generate virtual cards to pay vendors. OTAs, like our partner Swile Business Travel, centralize travel booking and payment for corporate employees. They charge their customers a recurring per seat fee for access to the (paid) platform. But they also make money in a different way.
A hypothetical user of the Swile platform, let’s call her Louise, books a flight to Paris from New York. Swile's software facilitates the booking and does not ask for payment from Louise; her company pays Swile at the end of every billing cycle for all employee trips.
Who pays the airline then? And how?
Swile Business Travel, using Swan’s banking API, generates a virtual card every time an end user books a trip. Then, the card details are shared with the vendor(s) who charge Swile on behalf of the traveler.
There are clear advantages to using virtual cards rather than bank transfers. Every card transaction is a source of revenue for both the BaaS and the embedding partner due to shared interchange agreements with the card networks. Accounting and reconciliation is simplified for both the OTA and the vendor; payments are consolidated. Bank transfers are final; card transactions are not. They can be easily reversed via a chargeback process, which is useful in case of cancellations.
Embedded transfers for invoice financing
Swan’s ability to support automated SEPA transfers makes us a great partner for companies providing invoice financing features, also known as factoring. Aria, one of our long-standing customers, has solved an otherwise tricky pain point with us.
Aria provides lending to companies via invoice financing. Corporate customers deploy Aria to help their users get paid faster. A common use case involves freelancers, who often need access to cash quicker than multi-month billing cycles allow. Aria pays them immediately, using future payment on invoices as collateral.
The trouble is, Aria is not a banking institution. They are a software company that has built the API rails necessary to enable embedded lending.
Of course, by definition, making a loan requires money to move from the lender to the recipient. Without a banking license, Aria was not able to develop their own payment capabilities. Sure, they could open an account at Caisse d’Epargne and make use of open banking protocols to orchestrate transfers. But reliability, ownership, and ease of use are not guaranteed with such a set-up.
Here is where Swan comes in. Aria maintains one big account with Swan, in which all money to be lended is stored. When a loan is approved, Aria pings Swan using server-to-server consent protocols. A payment request is initiated and Swan’s smooth APIs prepare and facilitate a SEPA transfer from Aria’s Swan account directly to the IBAN of the loan recipient This can even be an instant SEPA transfer, enabling instant receipt of funds immediately after request, right when they need it.
Swan is truly the perfect partner to provide this missing link that makes the whole Aria product experience possible. A Swan account gives the company a place to store money. And our best-in-class payment orchestration APIs ensure that Aria’s end customers are financed, fast.
Embedded payment reconciliation capabilities
Here at Swan, we have a clever little feature we call Virtual IBANs that simplifies getting paid. Virtual IBANs improve the process of payment collection and reconciliation for the recipient while keeping the sender UX unchanged.
Say you have a bank account. It has an IBAN (International Bank Account Number) so that it can receive transfers from other accounts. The purpose of a Virtual IBAN is to fashion a simple & quick way to identify those who send money to you. You can assign Payer A Virtual IBAN 1, Payer B Virtual IBAN 2, and so on. But the money all flows to the same place: the main account.
Our partner OQORO is the paradigmatic use case for Virtual IBANs. The company is a digital rental agency. They manage properties in all corners of France on behalf of landlords. OQORO, like Aria, has one big Swan account, used to collect and store rental payments.
In a Virtual IBAN-less world, all rental payments arrive into the main account. The tenant is responsible for including reference data that makes the payment trackable. This is usually done by encoding a reference ID in the rich text data that accompanies the cash transfer itself. But, mistakes are often made (such as omitting the reference ID or missing a digit). Even if the reference data is right, it is quite taxing to figure out which tenants might be late with their rent.
Virtual IBANs issued by Swan go to great lengths to simplify this problem. Every renter is assigned a Virtual IBAN, to which they are asked to send their rental payments. Then, whether viewing the payment data in our Web Banking dashboard or in more raw format, every payment can be seamlessly matched by the property manager with information about the tenant. This makes reconciliation a breeze, regardless of whether or not the tenant includes reference data!
Level up your internal financial workflows!
Many of our partners are using our banking features via API to improve customer experience, increase revenue, and make their businesses more defensible by delivering banking features to their customers.
Swan does more than just provide some of Europe’s best companies with the capability to offer banking features to their customers, however. We also provide our partners with the missing link that enables them to facilitate B2B payments, provide invoice financing, and seamlessly collect and reconcile payments.
Internally embedded finance can arguably deliver even more value for companies looking to put together a great piece of tech with banking features and capabilities at its core.
Please reach out to us if you would like to explore more about what we can build together!
.jpg)
