Sessions of money, data, and trust

The internet is full of sessions. From the most the most obvious to obscure — browser sessions, driving a car, phone calls, playing a game, and too many other examples to list.

One of the design considerations for Dwolla’s Labels technology was how to grant access to something that can’t own an asset. Like a car, television, or even something somewhat ephemeral like a session.

One of these things may just need temporary access for the purpose of fulfilling a job. When sessions are tied to real money in a regulated financial institution and made available in real-time, things get really interesting. This article is about how you could accomplish that building on the Dwolla platform.

Below is how the Dwolla Labels ownership stack works at a high level. It’s worth noting that this post assumes you have a good grasp on Dwolla Customer Types.

• Master App Owner (Master Balance owner) – Funds held in regulated FI
  • VCR Balance – Owned by the VCR end user – Funds held in regulated FI
    • Label Allocation 1 – Owned by the VCR end user allocated for purpose 1
    • Label Allocation 2 – Owned by the VCR end user allocated for purpose 2
    • Label Allocation 3 – Owned by the VCR end user allocated for purpose 3

The master application owner has authority to create customer records (RO, VCR, uCR) and grant access to the owners of those records through the software application that the master application owner operates.

The master application owner also has the authority with the end users permission to allocate funds on behalf of the end user for a specific purpose. When labeled funds are simply segmented away and allocated for a unique purpose, they can be reallocated or unallocated on demand.

In a credit card environment this takes the form of an authorization and funds are made unavailable until a future time. If you’ve pumped gas anytime in the last 10 years and paid with a plastic card you’ve probably seen this hold or authorization take place. Our view of this is that it could be much lighter weight if it was solved at the network/platform level. With the Dwolla implementation, in theory you could stream allocations to and from a label in real time at virtually no-cost. This would also allow the receiving merchant and even vendors to be paid much more quickly than in a traditional settlement model.

I get really excited about streaming money because it opens up the possibility to attach balances to realtime sessions across the internet. An example I’ve used a few times is how to do this in a web browser where there are many sessions running in tandem.

Here is how you could think about it.

• VCR Balance – Owned by the VCR end user
  • Label Allocation 1 – Owned by the VCR end user, assigned to a specific session.
  • Label Allocation 2 – Owned by the VCR end user , assigned to a specific session.
  • Label Allocation 3 – Owned by the VCR end user

Labels are intended to be used in a dynamic way and can be allocated or updated second by second. Each label has a GUID attached to it making it easy to track.

So if I were Google… How could I associate an asset allocation to a session, in real time, across an entire ecosystem? Here is how something like that could be done using Dwolla’s Labels infrastructure. Here is the ownership stack.

• Dwolla Application Owner (Google)
  • VCR 1 Balance (Google)
    • Label Allocation 1 (Association of ID to instance 1)
    • Label Allocation 2 (Association of ID to instance 2)
    • Label Allocation 3 (Association of ID to instance 3)
    • So and so forth into infinity

This is fundamentally different than the way we think of the ownership of money traditionally because this approach grants trust to a third party end user who does not own the funds, but for a period of time has trusted access enabled by the owner.

Trust first rather than ownership first is an important concept from my perspective. Trust is implicit in this structure because there has to be an enabling owner of the money willing to grant their money to a third party something because they trust it. The trust is explicit.

Whomever or whatever is on the other side of the session is irrelevant from a technical perspective.

In an ecosystem like Google’s that includes participants like Youtube stars, webmasters, and ad buyers there are some dynamic applications. There are millions of reasons you could associate a balance to a session. Technically speaking though there hasn’t been an easy way to pull it off until now.

Designing for trust first and ownership second as an end user, removes some interesting variables. For example, how do you CIP verify a browser session? One could argue that you can’t, but you could CIP verify everyone who could possibly use it. That would be extremely expensive though and probably not very reliable. Our approach here has been to enable the CIP verified owner to trust a third party with use of their asset. In the event they take possession of it, verification applies at that time.

Using this approach, a developer can build an application that enables end users to:

• Enable access to an asset
  • On a per session or many session basis
  • To a third party computer that never owns the assets
• Convert trust to ownership of an asset when the time calls for it

In my example, funds would always be owned by Google, until they are not. End users of the sessions enabled by Google simply select to trust Google. What sessions have trusted access to what allocations is explicit, which is important. It is also implicit that if the session itself takes ownership of the funds in totality that ownership must be transferred.

In a traditional model you have to first have the ability to own something before that something can be given to you. In a more internet friendly model it’s fine to own nothing and trust a third party to deliver something to you that you don’t own. Again, trust rather than ownership first.

A further abstraction is when two Labels which are trusted machines or software select to trust one another. You end up with all this potential machine-to-machine commerce.

Data is cached for the purpose of sessions and if money is really data why can’t it also follow suit? The internet is fundamentally built and enabled on trust.

In this example, we assume trust is the starting point and at a later point in time a person or company may want to acquire ownership of an allocation. That is a solved technical problem.

To program that kind of trust to ownership conversion with the Dwolla platform there are important things to remember:

• Labels have updates
• Customer Types have transfers
• Updates are not transfers

If you’re updating a Label with the intent of putting it into a US bank account, here are the order of things:

Step 1. Update
Update Label, to VCR,
Step 2. Transfer
Source VCR Destination RO

The corresponding UX of this would be an end user (User of Browser 1 session 1 for example) saying “take these funds associated with my session and place them in my bank account.” Bank details and ID information would be supplied when creating the RO Customer Record, attached as a funding source, and then used with the transfer is initiated. Effectively a payout right to the bank account from Google in this example to the end user.

If you want to segment the funds off in a wallet type account owned by the end user of Browser 1, here are the order of things:

Step 1. Update
Update Label to VCR
Step 2. Transfer
Source VCR Destination VCR

In this example, the balance would still be held on platform but is now owned directly by the end user rather than Google. The last VCR in this example would be owned by the end user directly.

If you want to settle the funds out to another provider or internationally, here is the order of things:

We’ve seen various application owners also start to partner with banks to include them as the final VCR in that payment flow or connector between systems.

As if this is not fringe enough for you today, the Dwolla team also developed an implementation of Cloudflare workers to enable caching the labels balance at the edge. The experiment was more intellectual than anything else and demonstrated some major changes in thinking about speed. The Cloudflare proof of concept tested our ability to make real-time decisions based on available funds in sub 50ms windows.

Disclaimer: This post was written without input from Google, doesn’t have their consent, and represents my own views. If you’re from Google and want me to take it down just let me know and I’ll be happy to swap your name with a fictitious company. I thought the example was easier given a company name everyone was familiar with. If you are from Google though (or anywhere else), it’s worth noting that everything I just typed is available and in production today in the Dwolla API. It’s just a configuration of the building blocks that requires some work.