Ever since I wrote that post about making the web fast I've been running thought experiments for the various websites I described and for many of them there is a shared keystone: the banking site.
In the original post I assumed that a banking site would be a thin veneer over the top of an existing, traditional, banking system but when I started thinking about building some of the other websites I found that I need a way to provide that banking function and I don't happen to operate a bank that I can "skin" with a website and electronic interface.
So I started thinking about how I would implement such a thing "from scratch", and came-up with CybreCredit. The most obvious way for me to describe it is to walk-through the process of using it, so here we go...
To begin, you visit the website of a CybreCredit branch and enter your email address. You'll receive an email with a link you can click to log-in.
This email-based, passwordless authentication is used throughout all of the websites I'll be describing in this series. I hate passwords, and authentication itself is something I want to eliminate as much as possible and the only complication I can see to this mechanism is handling email address changes smoothly.
Since this is your first time logging-in a new account will be created for you with a $200.00 credit limit. You'll be prompted to enter a PIN which will you'll be required to present for any transaction that places a charge against your account. Once you select a PIN you'll be taken to the Transactions page. This page displays your remaining credit at the top along with a list of transactions for the current month. It also contains a "New" button you can use to create a new transaction for things like sending money to a friend, transferring funds to another account, etc.
Selecting a transaction from the transaction list displays the Transaction Detail page which includes the transaction date, amount, account the transaction was made with and detailed information about the transaction provided by the person or system who created it. This page also includes a "Dispute" button that can be used to challenge transactions that you're not sure about (transactions can only be disputed during the month in which they take place, after that they are permanent).
In addition to the Transaction List and Transaction Detail pages there is an Account page where you can provide additional details about yourself as well as download statements and find information about to paying-off your balance.
At this point you're ready to buy some things!
When you visit an ecommerce site and make a purchase, you need only provide:
* Your CyberCredit account name (branchname@your.email@yourdomain.com)
* Your PIN
The ecommerce site will then process the sale like so:
1. Check your available credit to make sure you have enough for the purchase
2. Fulfill the purchase
3. Charge the final purchase amount against your account
Steps 1 and 2 are simple REST-style HTTP requests against the branch's CybreCredit API. Two requests are needed in case something goes wrong during the fulfillment process to prevent getting charged for something that wasn't delivered, etc.
The final transaction amount will include a 1% transaction fee that goes to an account owned by the branch. CybreCredit doesn't charge interest because charging interest is a sin, so operating costs are covered by a simple, flat fee applied to all transactions. Whether this is presented as a fee to the buyer or "baked-in" to the price of goods is up to the vendor's discretion, but it will always be 1% forever.
Back at the branch, the requests are displayed as a transaction in the transaction list. Only one transaction is displayed as the initial "auth" request will be replaced by the actual charge request once it's completed.
Once a month all transactions are rolled-up into a statement that is available for download from the Account page and the transaction list is cleared. After the statement is generated you'll get an email indicating that the statement is available and a request to pay your outstanding balance. There is no penalty for unpaid balances other than the fact that the balance is carried-over into the next month, reducing the available credit. Each time you pay-off the balance, your credit limit will be increased by the amount of the payment.
I find this interest-free/debt-oriented approach interesting because it allows people to dip their toes into the system without having to invest any real currency. You can try things out with little risk beyond spending some of your time. It is a little tricky because of course there is a high likelihood that accounts will accumulate debt that is never paid-off, but as far as I can tell it's only ever the branch's problem (buyers get their goods, sellers get their payment) and by keeping the initial credit limit fixed and somewhat low the risk is somewhat predictable. This, coupled with the fact that I imagine at least the early shopping experiences in this experiment will be digital goods with at least potentially zero costs after producing the first unit make the whole gamble somewhat safe (I think).
How do you pay-off your balance? The simplest way is to remit a payment to the branch in whatever currency they accept. Another way is to provide services to other members who compensate you by transferring funds to your account. You could also open an ecommerce site and sell products.
"just open an ecommerce site" might sound like I'm ignoring the significance of the cost of such an endeavor but I have some ideas about how to make that a lot more accessible that I'll talk more about in a future post about CybreMall.
The last thing I'll mention about CybreCredit in this post is branches. In order to keep scale in check, the system is designed so that the size of a given server is limited. I'm not exactly sure what this limit is yet but it will be a matter of how many accounts or transactions-per-minute the reference hardware can reliably sustain. My SWAG is 1000 accounts. So CybreCredit is designed to work in a distributed fashion, and by including the branch name in account names it's fairly simple to determine which branch should process a given transaction. Exactly how two branches coordinate such a transfer is something I need to think about more (I have a few ideas but I want to simulate things a bit more), but this allows the system to grow without a huge up-front investment and reduces the "blast radius" of outages or failures.
I must admit that this kind of feels like it might be illegal, or at least be subject to some sort of regulation, but on the other hand I don't see how it's any different from the "in-game" currencies used by things like Fortnite or any other game in which you can buy in-game credit using meat-world currency. For now I'm not going to worry about it because at this point it's all theoretical, but if someone knows more about this than I do I'd love to hear from them.
Jason J. Gullickson, 2026