Barclays & Digital Catapult National Business Challenge Event
At very short notice - and that was our fault entirely - we found out about the Barclays and Digital Catapult Challenge.
As described by them, the challenge was designed to allow Barclays to reach out to innovative tech companies and help design and build solutions. The link is here for anyone who wants to read a bit more about the set up, and, without this wishing to sound like a note from our sponsors, we should here pass on our thanks to the teams at the Digital Catapult and Barclays. The whole thing really was well run, and enjoyable.
There were a handful of challenges and the two that seemed of most interest to us were “Improving the Customer Identification Process in Branch”, and "Designing a paperless direct debit system".
The turnaround from brief to pitch was 30 hours and we took the view that we needed to respond with a working prototype - in one response at least - in order to stand out from the competition.
Customer ID
With its various tensions it is easy to imagine how important it is to get this right - customer service implications, a large changing template of acceptable documentation, legal penalties in breach etc.
It seemed to us that there were two ways to think about the problem: (i) is the documentation-set in order? vs. (ii) does the person in front of me belong to the documentation set she produces?
We spent time on presenting a solution for case (i) - our solution had you using your mobile to pre-scan much of the doc-set to be Barclays-approved purely on the grounds of its integrity; this allowed for any subsequent in-person appointment slots in-branch to be more time-effective (a major impediment to success given glitches created by in-house turnaround times on doc verification).
Turns out we guessed incorrectly: Barclays were more interested in (ii), which to be fair is a more interesting problem.
Oh well, lose some, lose some.
Paperless Payments: am I Pushing or Pulling?
Of course Barclays has pingit - a push system allowing the user (anyone who signs up, not just Barclays customers) to make payments directed to any UK mobile (rather than by supplying account details).
Problem solved? Well no, Barclays were interested in a pull system, where a user can also ask for payments (think clubs, memberships and the like where the counterparty doesn't want to go through the formality of signing a direct debit).
Well, we all know why push exists before pull when it comes to payments, and let's face it, at Circadian we weren't about to reinvent a more dangerous pullit in 24hrs. So, we thought instead to add a chameleon-like interface: confuse the distinction between a pull request and a push.
Our interface allowed the pull requester to send (we built templates that were delivered by either SMS or email) the pull request to the UK counterparty ('please wire me your £100 for the boat trip by Monday'). As mentioned previously, request, not pull is the operative term there. The recipient then chooses to accept or reject the request.
Acceptances automatically led to -
(i) in its absence, pingit registration (one of the great things about pingit is that only the payor need sign up); and
(ii) an automatic push to the phone number the request came from.
We had our mock-up interface complete with fully-working user-authorisation, pingit-linkage, SMS formatted payment requests, and accept/reject responses delivered in the time slot.
Whilst the turnaround time did impress the team at Barclays (nothing better than having their phones zap as you speak), unfortunately we didn't win, coming second instead. Admittedly we were a little disappointed not to be claiming the glory, but we did also feel fairly pleased about the outcome having arrived at the party at such a late hour.
In any case, if you would like to see the url we built for the interface please just drop us a line and we'd be very happy to point you to it as well as to give you a walk through.