The Culture of Design(ing) Systems: Key takeaways
We summarize the insights from Somo's UX Lead Designer, Eric Smallwood's talk at MarketsandMarkets Design Thinking Virtual Summit.Read more
At Somo, we pride ourselves on helping companies that need a little dash of magic in their everyday operations with our own special sauce composed of technical expertise, innovation, creativity and fierce, unrelenting chillis. Normally this traffic of ideas and hot sauce is very much from us to our clients, but every so often someone comes to us with something just as innovative, brilliant and spicy as we hope to be ourselves.
swIDch (pronounced "switch") are a subsidiary of SSenStone, an established Korean company specialising in security and identity management. Their CEO and technical mastermind, Chang-Hun Yoo, has developed a number of algorithms to allow users to identify themselves securely, yet conveniently; he had developed a new one that could transform card payments. Would we take a look?
My interest was piqued. Over the ensuing several weeks, we got to learn a lot about this revolutionary idea—and had to come up with a few of our own.
A credit or debit card is essentially a means of identifying an account belonging to a specific person. The card, and the numbers on it, are intended to be carefully kept secret, only entered into trusted payment devices. As long as the card is kept securely, this system works.
However, in the modern world, there are many more ways to steal these details than when credit cards were invented. In particular, online payments are vulnerable to attacks such as phishing, where a legitimate-looking payment gateway actually funnels valuable card numbers into an attacker’s database.
This is the problem of card-not-present fraud. Card-present fraud—where a card has been physically stolen—is now relatively rare in countries that have implemented EMV (chip and pin or chip and signature), but card-not-present fraud is estimated to be worth between $25bn and $40bn globally, accounting for roughly 4% of all transactions. That’s an astonishing leak.
Clearly, this is a leak worth plugging. But given the need to identify billions of daily users and transfer money between their bank accounts, it seems hard to imagine how. How can you identify a user without a card number? How can you unlock a bank vault without handing over the key?
swIDch essentially asked the following question: what if a user could be identified not by a fixed number, but one that changes constantly and can only be used a single time?
The advantage is obvious. If a malicious actor somehow manages to acquire the card number, it will expire very quickly, rendering it immediately useless. The challenge, however, is just as obvious: how can a user be allocated a constant, seemingly random stream of new numbers, yet never clash with other users?
This is where the ingenuity of the swIDch algorithm comes in. Without getting into detail, the essence of the algorithm is to combine three pieces of information: a public ID, a secret ID, and the time.
The public ID, by its nature, doesn’t need to be encrypted. The private ID does, and is, using a conventional strong encryption system. These unencrypted and encrypted elements are then merged and combined with the time to produce a single long number, which can be split into a card number, a card expiry date, and a Card Verification Code, or CVC.
Because the public ID is fixed, and the time is the same for everyone (as long as you don’t travel too close to the speed of light), the numbers cannot clash. A user can therefore be identified uniquely. The encrypted, secret ID is then used to check that the user is indeed who they say they are.
swIDch had identified an important, expensive problem and found a brilliant, elegant solution. Unfortunately, the world is rarely so elegant. For excellent reasons, it is very difficult to get a technology approved for use in real payments: the stakes, as we have already seen, are extremely high.
Now, payment flows are quite complex. Multiple systems interlock to check the identity of the cardholder, to find the associated bank account and check whether it has enough money to fulfil the transaction, and to transfer money to the destination account; the merchant’s system must then track this transaction to allow the actual goods being bought to be supplied to the user. To show a really convincing demonstration of the viability of swIDch, we needed to perform a complete transaction flow using the technology.
This meant we needed to make a bank, and an online shop.
Although, obviously, both bank and shop are fictitious, they nevertheless needed to be real enough to do the following things: put a (fictitious) card number into the payment page of the shop, pass this card number to the bank, determine whether the account associated with the card had sufficient funds, then transfer the right amount of those funds to the shop account, then, finally, tell the shop how all that had gone, so they could tell the user whether the transaction had succeeded.
We then needed to do all that again—using swIDch.
In real life, a transaction has to deal with the fact that the parties often use different banks. For the purposes of the POC, we cheerfully ignored this. Instead, we built a single, extremely simple bank, designed to do nothing more than fulfil the kind of transaction described above.
The bank's users can each have several accounts, with balances and credit limits. Each account can make direct transfers to any other account.
Each account can also have cards associated with it. But our bank didn't just need to handle its own cards: the card number coming in could also be a swIDch card. We needed a way to deal with these differently, sending them out to the entirely separate computer system housing swIDch's clever algorithm. Fortunately, card issuers have already solved that problem.
A sixteen-digit card number splits into three parts.
The first part is the six-digit Bank Identification Number, or BIN. This is unique to a specific type of card from a specific issuer. This is how payment websites can figure out whether your card is Visa or Mastercard or something else, for example, and display the correct logo.
The second part is the card number proper, unique to any given user. These digits can have any value.
The last digit, the sixteenth, is a check digit. It's created by putting the previous numbers through a calculation called the Luhn algorithm, and it's a way of making sure none of the other numbers have been entered incorrectly.
swIDch numbers have to obey these constraints like any other card number. We decided to take advantage of this: by having all swIDch cards start with a known set of six digits, we could route swIDch numbers to the token server containing the swIDch algorithm, then deal with any other numbers ourselves.
The token server will take any valid, current swIDch number and return a set of conventional card details associated with that user. These are then resolved as they would be in a conventional payment flow.
This means the bank allows an extremely simplified version of both conventional payments, and payments using swIDch—exactly what we need to prove the concept of swIDch as something that could be used in a real-world payment flow.
Of course, payments aren’t much use unless you can buy something. We set up an extremely abbreviated online shop we called Nile.com (we pictured it as being wholly owned by Nile Rodgers and the Chic organisation). Of course there are no real products; however, you can follow a payment flow through its entire journey from product selection to checkout, and then see the flow of “money” in the bank.
We even issued our own cards:
(For the linguistically minded, the German for switch is Schalter.)
Incidentally, this is where the Luhn algorithm comes back into play: the card scanner we built into the swIDch app uses it to check whether a card number is valid. All our card numbers therefore had to obey the Luhn algorithm: cue an extremely hasty implementation of said algorithm in a Google sheet by me.
All this infrastructure was assembled in about a week by one of our superb developers using serverless functions hosted on AWS. This led one of our founders to refer to the project, in a fit of enthusiasm, as "the world's first serverless bank". While we are a long way off the complexity of a real bank, there's no technical reason why the exact same principles we used to make this couldn't be used to back, for example, a complete implementation of the Open Banking API.
We now have a serverless (and extremely simplified) bank and an e-commerce site with no physical products (but a legend of music as its owner)—the ingredients we need to demonstrate swIDch payments in a realistic setting.
We first tested the system on one of our static card numbers; it worked flawlessly. Checking the balances, we could see that the right amount of "money" had moved from one account to another. Would it work with swIDch?
As is so often the case, all was not flawless victory from the word go. However, this was in fact very useful. The initial hiccups we experienced showed that the system would not work without every piece of the puzzle perfectly connected. In any system where security is critical—and this is a very security-critical application—proving this is vital. In this case, the puzzle pieces didn't fit because we hadn't lined them up quite perfectly; however, this proved the value of the system once we did have our ducks in a row.
The system now works exactly as designed; it's been used to demonstrate the technology to some interested people, and will continue to do so.
We've been very excited to work with swIDch on this project; they have been delightful partners in innovation, and it's always a pleasure to do work involving such a free and open sharing of ideas and expertise in both directions. Their next step is to take this technology and find a way to bring it to the real world. We hope to be right alongside them as they do.
To learn more about swIDch, visit http://www.swidch.com/