lennyevans

Yup, we haven't seen an issue with semi-transparent cards or maestro cards and have built-in support for the vertical cards as well (though we're still trying to optimize the UI/UX for that so let us know if you have ideas!). We don't support girocard yet, but we're working on adding support for that.

Currently it's only available on iOS and Android apps, with mobile web coming soon. We're still working out exactly what the experience will look like on desktop (it's a less natural flow for sure), but once we work out the kinks we'll be building that out as well.

Sorry, I unfortunately can't reveal too much about the training data. As for tips on optimizing models for device, choosing a fully convolutional architecture is almost a requirement as any substantial fully connected layer is going to take up too much space. For convolutional layers you want to use more efficient versions like depthwise separable convolutions. Using quantization is a pretty easy way to reduce the size of the model without sacrificing too much performance as well.

Lena here: Certainly, other people can do it, but it would be quite an investment for them. Here are some reasons why:

• The on-device tools are still in their infancy, and so it was actually a lot of work for us just to figure out what configuration of framework would work in a production system. For example, we can't use coreml for our iOS framework since it is only supported on iOS 11+ and many apps still support iOS 9+.

• There's very strict model size and performance constraints that require us to really optimize our model. App binary sizes are often tightly controlled in mobile first companies so we don't have much wiggle room in terms of how large our network can be. On top of that, we want the model to run reliably and quickly on phones from 5 years ago (which are still used today), when the hardware was much worse than it is today.

• Getting the training data for the model isn't easy.

• The model needs to be maintained, so any company that tries to do this would need to have a dedicated team on it. Credit card providers are constantly changing the style of cards they make (for example the new Visa Quickread format), and the framework has to be updated to keep up with this.

Lena here: completely agree avip. In terms of fraud losses, most companies are really worried about fraudsters that can scale their operations, not super targeted attacks. If you can increase the cost (in terms of time and money) of committing fraud, it becomes less scalable and less profitable for the fraudster. So certainly, a fraudster can get a card embossing kit and start making cards, but this is going to be much slower. Without our solution fraudsters are just typing in a card number, which takes seconds! Unless each instance of fraud is highly valuable (for example, as is the case with banks as Julia mentioned earlier), the economics start to look worse and worse. On top of that (and this certainly applies more to any deep-learning based solutions trying to bypass us) our models will constantly improve and so we'll force the fraudsters to constantly improve any fake card generation, making the fraudsters spend time on that rather than defrauding.