As you might have noticed, we are nearly ready to launch P2P (person-to-person) payments and are currently testing it internally 
We’ll probably launch it publicly next week(ish) but if you’re up for testing it now (Mondo to Mondo only for now), drop us a message through in-app chat!
5 Likes
I would but wouldn’t be able to use it until I can add some family members. Any news on that side?
There will be next week 
2 Likes
Tested both sending and receiving, working as intended 
1 Like
I have also had a good play with it. Seems to work very well.
I was very uncomfortable with the idea of entering my card’s PIN though. To me, that’s something which should always remain offline and only used when my card’s chip is involved. I did highlight this to Leah though.
Also my app now says I’ve spent over 1k today, though the net amount is about zero. Would be nice to be able to flag transactions as not counting towards my spend, or showing the net amount rather than just outgoing.
2 Likes
In a way, what surprised me most about the PIN entry is that you know what my PIN is. I would have thought/hoped that it was not readable or accessible by your web APIs at all.
Sorry to hear this makes you feel uncomfortable. We chose to use the PIN because:
- it should take more than just access to a person’s phone to make a P2P payment
- we’d like to avoid things like additional passwords (as you may have seen, we removed passwords entirely in the latest release)
- the PIN is something everyone already knows
The real PIN isn’t sent to your phone – instead, what you type is sent to the server which validates it. After a number of unsuccessful tries the process is blocked, just as it is for a Chip + PIN transaction.
If there’s something else you’d prefer we used instead of the PIN, I’d love to hear
Indeed - I am well aware that the PIN is validated server-side. It’s still concerning that the PIN is accessible inside your public-facing application servers. Makes me wonder what other critically sensitive data isn’t air-gapped correctly.
I’d much prefer a 2-fac authentication method other than the PIN - for example, a code sent via SMS or email which expires after a minute or so.
There’s also the very real potential phishing aspects. Most of these are obvious, but one to call out is that once you have a website which allows the movement of money, you have much less control over the execution environment. For example, Chrome extensions routinely inject JavaScript into web pages - often from external servers which could be compromised, then making it trivial to intercept the PIN.
Ultimately, my opinion on this comes down to two core points:
- a card’s PIN should only ever be inputted in relation to card present transactions (I would think PCI mentions this also)
- in a scenario where the entry of an important authentication code may be phished or intercepted, that code should be both time-limited and one-time-use - never a code which could be used again
5 Likes
Hi James, excellent feedback as always. We’re working on 2-fac methods that don’t rely on anything that can’t be gained by stealing an unlocked phone (which generally includes OTP via email or SMS). It’s not an easy problem to solve
I agree with your point on phishing, we wouldn’t want to expose the PIN 2-fac interface in an environment we don’t control.
Yes that’s totally true. I’m not sure what would be truly secure for the 2-fac other than the physical ones provided by HSBC, etc.
Nobody wants those silly key fobs though 
One thing which might interest you is that there are a few behavioral analysis tools now which can roughly check whether the person using the device is the same as the person who normally uses the device. This is not at all a binary check, but can help with general fraud detection. I’ve talked with a company called Zighra who have this technology for phones. Happy to intro if interested.
Also one thing worth consideration is that even the iPhone execution environment can’t be completely controlled.
A system became available recently called Extensify which allows you to inject code into iOS apps without jailbreaking - through simple method swizzling.
Voice recognition, face recognition or your thumbprint to unlock a secret that is exchanged during signup (or when you change devices) are examples of things we might use. I think of it less as discrete factors and more as a large pool of factors that together result in a confidence score. If you’d like to take an action that exceeds the current confidence score, you will need to provide additional factors.
Behavioural analysis, your location, a device fingerprint, amount of storage left on device, etc are all small factors we could consider in such a confidence score.
I’d love an intro to Zighra if you think they’re particularly good at what they do and would be easy to work with You can email me at jonas@getmondo.co.uk
3 Likes
I think PCI explicitly block the use of touch screens for PIN input. It’s why people like PayPal and iZettle both have Bluetooth card readers.
I’m not sure it’s a good idea to train users into thinking that entering their card PIN on a touchscreen is safe. The potential for someone use that in a phishing scam is a bit scary.
3 Likes
Yes, the specific regulations are explained here: https://www.pcisecuritystandards.org/pdfs/pci_ped_technical_faqs.pdf
While it isn’t actually explicitly disallowed, it would need to be supported by the device manufacturer. So far, only one company has built hardware which is certified - Cryptera. I think it is exceptionally unlikely that Apple will ever do this, let alone any Android phone manufacturers.
I suspect that Mondo actually isn’t required to follow PCI - as they’re on the other side of the table. More likely, they will be covered by the MasterCard issuer certification program, which differs in many ways from PCI. This doesn’t change the fact though that Mondo should aim to operate within PCI anyway.