Trading With Digital IOUs.

For the past couple of years, I have been talking around the world about the Fragments State of Our Payment Systems.

With over 1,900 payment systems around the world, less than 3 percents are connected and can talk to each other directly or using one hop.

Think about that for a minute, what a mammoth opportunity that represents, but more on that later on.

In the previous article, I explained how the Digital IOUs work. They are not decentralized but centralized (as the issuing authority has to have control, which in this case was the bank).

We will eventually gravitate towards the decentralized IOUs, but that will take some time. We have to have a hybrid solution before we have a solution where audits can be done and funds in escrow – tied to the coins can be verified.

I do want to stress, there are many models on how the stable coins or de-tethered digital IOUs can be managed and traded.

So how might digital IOUs be traded, here is one such example:

A bank issues IOUs as described in the previous article (The e-Fiat Story: From the Physical Cheque to the Digital IOU). These IOUs would need a platform issuer that the bank can work with. Everex, for example, is one such issuer. They can manage eFiat tokens and have them traded transparently over the Ethereum blockchain (which is a proven blockchain technology).

As cited previously, there are quite a few solution providers that a bank can go to, asking them to manage in a transparent, yet secure and compliant way, within the regulatory framework the digital IOUs (or eFiat) tokens.

Payment Problem # 1

Let us assume there is an aspiring publisher based in Accra, Ghana. The publisher has subscribed to the Rubicon Ad Network. Every day, this person updates content on his various websites, that generates traffic and ads are shown. After weeks of hard work, steady traffic has started to come in. The publisher earns about $5 in ad revenue per day.

At the end of a working week, Rubicon is holding on to $25 of this publisher’s money. But because there is no efficient (read: cost-effective) method of transferring money from the US to Ghana, the publisher must suffer.

The publisher has to now wait for until his balance reaches $500 before Rubicon is able to push the amount out (as a cost of $30 to the publisher) and it might take a day or two.

The publisher can sure put food on his family’s kitchen table if there was a method for them to receive his money earlier, and as close to the balance amount that Rubicon is holding for him.

Payment Problem # 2

Lufthansa Cargo operates 100s of flights every day. Sometimes they make unscheduled stops to airports around the world. In one such case, a Lufthansa Cargo plane had to make an emergency landing in Abuja, Nigeria. After the emergency was deemed to be over, the plane refueled and took off. The crew had some meals at the local cafeteria and owed them $37.

The bill was settled by a local fuel company rep at the airport and the crew was obligated to send the rep $37.

Back home at the Lufthansa HQ, there was no way HQ could possibly process $37 due on an invoice to Nigeria, as it would cost them €20 wiring fees and yet they would have no idea how much amount would be received by the rep (assuming there are zero deductions by the correspondent banks).

Payment Problem # 3

A freelancer is working on a daily wages basis. Mostly mechanical Turk type work. They do some task for a given period of time or number of times and they earn an income on it. Some do it on weekends only, some on Tuesdays (when they have free time) and some, on a 5-days-a-week basis.

As with the Rubicon Project, their income is with the marketplace that they were working for. Again, the same situation applies, they need to get micro-amounts transferred, and that too immediately. However, the marketplace has a provider that insists on $500 as the minimum balance before they will move the money and charge a sizable fee for it.

Being able to earn a daily wage from worldwide marketplaces without subscribing to a foreign wallet or prepaid debit card (where the deductions are higher) is not a viable solution.

A Proposed Method of Working With Stable Coins – Digital IOUs

In the case of the publisher from Ghana, here is a proposed solution:

The solution provider for payments, for Rubicon, can purchase eUSD Token by paying a 20 basis points price above the denominated value (20 Basis points = 0.20%)

They buy for example $100.000 worth of eUSD tokens from an exchange that is offering this in partnership with a bank (let us say Everex is doing this).

Now the cost to the Payment Service Provider (PSP) is: $100.200

The PSP charges Rubicon 3.5% to deliver the amount. It is always 3.5% of the amount being delivered.

So in this case: 3.5% of $25.000 = $0.875 is the charge for delivery.

Total Cost to Project Rubicon: $25.875

The Payout Partner (PP) in Ghana will charge say 1.25% for delivering funds to the local bank account.

So, for $25.000, the charge is: $0.3125

So the cost to PSP is $0.3125 and the total amount being sent is: $25.3125

The amount received by the Publisher, into his account is: $25.000

At the end of the transaction, this is how it played out:

PSP Buys eUSD: $100.000

Cost of eUSD Fees: $0.200 (for the entire $100.000)

Rubicon needs to transfer: $25.000

Cost to Rubicon: $0.875

PP Balance in eUSD: $25.000

PP Balance in eUSD for Fees: $0.3125

Summary Calculations

At the end of the day, Project Rubicon delivered the money to the Publisher in Ghana for a fraction of the cost ~ 9 cents (8.75 cents to be exact).

The Publisher in Ghana received the money in full $25.000

The PSP made a gross profit of 3.5% on the transaction or about $0.875

The cost of this transaction to Purchase the eUSD was: 0.2% x $25.000 = $0.050

The cost of this transaction as charged by the POP was: $0.3125

The net profit for PSP is: $0.875 - ($0.050 + $0.3125) = $0.5125

The eUSD that is held by the PP can be cashed in anytime with the exchange (Everex) for the full face value and zero fees.

That means, if the PP took say $500 worth of eUSD, the amount they would receive after cashing the balance from eUSD to USD is $500.

Now, this balance is kept with the bank. It can be wire-transferred in the traditional sense to the Payout Partner or they can buy more token for it.

Buy Price at Exchange is Face Value + 20 Basis Points.

Sell Price is Face Value + Zero Fees.

Bank makes money on the money it is holding in a deposit.

The fees are charged by the operator (like Everex, etc.)

3.25% is charged to the Marketplaces/Companies wanting to do small value transfer payouts is pretty decent income.

1.25% is charged by the Payout Partner is also very decent.

Conclusion

Is this a pipe dream? Certainly not. If you look at what the USDT is all about, it is pretty much the same, stable coins, with more visibility (read: audit) will be the norm going forward. It would be the perfect way to have trade & commercial payments made, using a trade-able bank-specific coin.

Moreover, going forward, you will see (hopefully) many of such coins being traded over an exchange.

What we haven’t even discussed in this model is the Foreign Exchange component. The income derived from it and how the revenue share will be done on that.

I am convinced that this case is a very workable case one that has a lot of potential. Transaction sizes that were too small to be commercially viable, are no longer – or are they?

 

This page was last updated on September 1, 2022.