Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Dyneti (YC W19) – Helping apps stop fraud and process payments faster
60 points by julia-zheng on Feb 12, 2019 | hide | past | favorite | 58 comments
Hi HN,

We’re Julia and Lena, the founders of Dyneti (https://dyneti.com). Our first product is DyScan, an SDK that helps apps stop fraud and process payments faster by taking a picture of a credit card (https://youtu.be/3gzDECAsqXs).

We met about 3 years ago at Uber, where we worked together to fight fraud on the platform. (Merchants are liable for fraud losses on digital transactions). One thing we noticed is a problem industry-wide is that while there is tons of investment in detection (rules and models and features), barely any work goes into figuring out what to do to someone after tagging them as fraudulent. Most of the reliable actions - the ones that actually stop fraud - are very severe (e.g., account banning). In order to minimize good users impacted, fraud systems are built to detect very specific fraud behaviors. It is therefore easy for fraudsters to reverse engineer models and rules and iterate around them, which means even more investment into detection.

Along those lines, we noticed few companies realize card scanning is a powerful tool to reduce fraud and improve digital transaction security. Stolen credit card fraud is a major contributor to payment fraud losses. Fraudsters attempting to pay with stolen cards rarely have the physical card on hand, but rather, are running through a list of stolen credit card numbers, expiration dates, and cvvs. Having people enter payment information through a card scan will only allow users with a physical card present to go through with payment. It’s extremely rare to have a tool that both improves customer experience and improves security - but an accurate card scanner accomplishes this.

In addition to being a powerful tool for fraud prevention, DyScan also provides a nontrivial conversion boost at checkout by reducing time and effort required to enter payment information (under 5 seconds for DyScan, compared to 21 seconds for manual entry). DyScan is also the only card scanner SDK that works on all credit card formats, including non-embossed numbers, numbers on the back, vertical cards, and Quick-Read format cards (those are the weird ones you may have seen around with a four-digit groups stacked on top of each other). Card.io, which is the card scanner experience you may have seen in other apps, works on only one credit card format (embossed numbers on the front of the card).

Other card scanners aren't great because they were constrained technologically at the time they were built. Due to PCI compliance, credit cards must be scanned on device, and it hasn’t been possible to get a good deep learning model small enough to do this until very recently (due to more neural net processing power on devices and better tooling). The additional benefit of this approach is that it means zero latency, which can make a huge difference in terms of user experience and user friction.

How it works: After an app integrates DyScan into its checkout process, their users can enter payment information by holding a credit card up to a smartphone camera. At the same time, DyScan verifies that the card is real and non-fraudulent. This results in more good transactions while bad transactions are blocked.

We’ve been working hard on DyScan for the past few months and are very excited to share it with the HN community and get your insights on what we’re building.

Thanks for reading!

Julia & Lena

I'm glad someone made tech that can scan my card with the numbers on the back, thanks! Hopefully all the vendors I use start using your product. I'll also be looking into it for my own product!

Regarding your fraud models, I actually used to work in this area (I'm pretty sure we know a lot of the same folks at Uber!) and I'm curious where you're getting your fraud model data from? Do you have partners you're working with? Until you have enough transaction volume, how will you train your models?

Cool!! Until we have enough transaction volume, we are replicating methods fraudsters use to create fake cards to train our models.

Not to make it sound simple, but all you’re doing is running a small neural net on device to identify multiple card formats. What prevents a payment gateway like stripe to do the same thing inhouse? Doesn’t sound like a very difficult thing, especially considering that tools to do on device ML have proliferated.

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.

I would add: Stripe might build this for themselves, and Apple might one day provide a native API. But there is also a good chance that they buy this tiny YC startup instead - gets them two former Uber engineers and an instant working API. Another credible path to exit is to sell to a dumber, slower company - like Visa. Fraud is a huge issue and big companies in the payment space are always hungry for pragmatic solutions like this.

If it's not revealing too much, can you tell us a bit more about how you got the necessary training data? And any tips on optimizing models for on-device ML?

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.

Ah, gotcha. This is a really cool idea. All the best.

Congrats on launching!

What happens to the photos of the cards?

Where is your privacy policy? I took a look at the site and didn't see one. They're required by CA law.

Thank you!

The photos of cards aren't stored anywhere - everything is analyzed on device to ensure privacy and compliance.

Re privacy policy - thanks, gotta put that up!

Does this mean the app is necessarily a trusted component here? What's to stop an adversary from reverse engineering the application, especially on a platform like Android where applications are side-loaded and binaries largely maintain source-level semantics?

I guess you could argue that, from the merchant's perspective, they just want to avoid being the easiest target.

Exactly - the effort required for this much beyond what most fraudsters would be willing to do on most platforms.

Sounds like it may be trivial for you all to make another app that does the same thing with IDs / identification..

I like the on-device privacy with your system. I could have used an ID check / age check thing like this a few times over the years. Some people have been good at taking a photo of their ID and emailing it or posting to a web form, others tried taking the top results on google for fake ID and using a picture of that...

I would not expect a system like this to detect 100%, but it could have easily cut in half the amount of terribly fake IDs that were sent in to us.. which sounds nice.

Might be an option for whichever company to add in a user select-able option to upload / send the pic in for human review (and further net training) as an option if it fails, or fails with a certain percent or something..

can see a lot of use cases for this, glad to see you all working on this.

Amazing - thanks for all the feedback. This is definitely on the roadmap - stay tuned!!

Danger on that front...

A company I worked with in the not so distant past got some real nastygrams.

There's a mountain of patents in that space that are near impossible to avoid stepping on.

Thank you much for sharing this. That's something I would not have even thought about.

On the flip side of that thinking, I wonder if that could be used to put all the places out of business that are trying to make the UK's 'you must prove age to see porn or nipples law' work, and if that would invalidate their law or just make it convenient that it could be impossible to implement and therefor just a backdoor to ban porn.

Interesting - would love to get more context if it's possible to share

I use physical cards very rarely. I prefer to use ApplePay wherever possible.

Where that isn’t possible, I prefer to use virtual cards that are created for me by my bank or by a service like privacy.com. They are single-merchant cards, so once they are used, they can’t be used with any other merchant. And I can put spending limits on them, and cancel them at any time.

With respect, I don’t trust your scanning mechanisms, nor do I trust the vendors (your customers) that would be permanently storing my credit card data.

So, what do you do regarding detecting credit card fraud for people using ApplePay or other legitimate virtual card providers?

Interesting - we're currently only detect credit card fraud for the segment of customers transacting with more typical credit cards (the largest chunk of the market) but this is good to know.

very awesome tech + privacy combo

Since fraud detection is done on-device, is there any clever encryption or security features that stop me from issuing a direct API request to the service with my (or someone else's) credit card info? If not, I'm worried that a technical fraudster could script their way around the ML model (and therefore not need the physical card), especially since cc lists are already nicely formatted. This would hurt pretty badly if the service assumes that DyScan is infallible and then doesn't have mechanisms for detecting fraud post-signup.

Great question! The company that owns the app is ultimately responsible for the encryption there, but there are a few ways we can help out with that as well (sorry, I know this is a terrible answer - but it's best practice not to reveal too much about how the encryption works)

This is a pretty good idea. Credential stuffing style CC fraud is a massive industry. Scanning could significantly raise the bar on fraudsters and give them much headache when it becomes widespread. Good luck!


Cool product! You should integrate with the Stripe wherever possible out of the gate. I use Stripe but still accept the CC info directly through their widget. You could really polish that phase for me.

On a side note: It annoys me when I see a page with little info on the homepage, I click "Demo", and I'm presented with a form. Why not at least put your Video on your Demo pages and then use the form for a "Personalized Demo" aka. sales call.

A stripe integration out of the gate would be REALLY nice :)

Thanks so much for the feedback! Just put it on my to-dos

Good opportunity. It's funny how many apps integrate with Card.io despite how limited it is and the fact that PayPal (which acquired it) open sourced it and stopped maintaining it years ago.

I think a big threat would be if Apple opened up their card scanning tech for adding cards to Apple Wallet as an SDK to developers. Personally I've found that experience to be really awesome and they can scan both embossed and non-embossed cards well.

Whoa you know a lot about Card.io!

Apple does have great card scanner. Our thoughts on this (would love to hear yours) are they have little incentive to open up the card scanning tech standalone for developers, but even assuming they did, the standalone Apple scanner wouldn't include any fraud prevention features.

Longer term, we plan to leverage data from our customer base to make our fraud prevention features very robust - and we suspect this would be difficult for a competitor to replicate.

Hello! Have you tested out semi-transparent cards (N26, ING) or vertical cards?


Bonus weirdness for tide cards: Name, credit card number, signature and cvv are all on the back, haha

Some Bank in Spain gives out vertical cards too, someone I know has one.

Also: Are Maestro cards supported? Girocards (EC cards)?

Most Germans have a girocard, way less hava got a debit/credit card.

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.

How does this flow work for desktop based e-commerce transactions, where a camera is not as easily integrated as mobile?

Edit: Actually it is quite trivial to request access to the camera via desktop now:

  navigator.mediaDevices.getUserMedia({ video: true })

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.

How does it know someone is holding an actual credit card and not a fake printed one?

There's a number of ways that a fake card will look different from a real card - we aggregate these signals and form a decision on real vs fake (sorry, we know that's a terrible answer - we would disclose more, but it's best practice to keep specifics of fraud detection a secret to maintain efficacy). Surprisingly, the gap between real and fake is wide enough that we can with good precision separate those cases. Of course, someone could build a replica indistinguishable from a real card, but at that point you've raise the barrier of committing fraud much higher than simply having a stolen credit card number, so chances are the fraudsters would migrate to some other platform

I once saw a presentation from BSI (Germany Cyber Security Agency) where a researcher used computer vision / AR to create a video feed of a realistically looking ID card based on a simple paper copy of the card. They could add reflections and holograms to the paper copy that looked absolutely realistic, and they were able to use it to pass a video-based identification test (Video-Ident) that's widely used by banks in Germany to remotely validate the identity of new customers. The company then had to change their validation method by asking people to not only hold up and tilt the passport (to reveal the holograms) but to also pass their hand in front of it while holding it, which would lead the AR algorithm to fail.

So I'd say it's definitely possible to fool even a person let alone an algorithm, as you said it's questionable though if there aren't any easier ways for criminals to use stolen card numbers.

Thanks for sharing that - super helpful to know.

Definitely agree it's possible to make good fake cards, but it makes it difficult enough that fraudsters will usually migrate to a different platform. Since banks are probably the most attractive business to fraudsters, we'd suspect banks would have to make life much more difficult for fraudsters than the average business in order to chase them away.

I do love the product and don't want to appear like I'm bashing it. Great work on lunching! Best of luck!

However, it seems if this practice (scanning card) becomes more widely adopted and becomes a standard process of detecting fraud, it'd become a relatively easy target for fraudsters to crack, right? I don't know if DL or card making technology will outpace fraudsters' will to make fake cards?

Further more, if I'm a fraudster and know some websites that adopt this policy, there is a big incentive for me to get a credit card embossing kit to start making cards, right? After all, I'd think it is far easier to make a copy of a card than making the magnetic strip thing? And given your tech is a strong signal of 'not fraud', if it is relatively easy to beat this system, wouldn't it attract a huge number of fraudsters?

I used to work in this field. The goal is not to create something unbeatable. The goal is to make something difficult enough that it becomes more cost effective for a fraudster to attack someone else instead. Acquiring thousands of credit card numbers and credentials (and even CVCs) is trivial. Actually converting those to real cash using real hardware is an incredible pain compared to just finding the least well defended e-commerce site out there that will sell you a gift card or bitcoin or whatever.

We used to say that our job wasn't to stop fraud, it was to move the attacks to Paypal instead. I don't have strong product opinions on this either way (personally I find all the card scanning apps to be incredibly annoying, but I think I'm a minority), but I do think it'll be a long time before I'd be worried about self-embossed cards being a meaningful attack vector.

Security is always about bar raising. Any protection can be bypassed. But for a non trivial period, fraudsters would be forced to try their CC listings on other apps, not protected by this tech. This will provide tremendous value to Dyneti's customers.

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.

Hi Lena, Great answer! Congrats on launching. I do have a few more counterpoints.

Thinking about this from a individual fraudster perspective. Acquiring a stolen cc is not an easy transaction, there is risk, and cost involved. So I think each fraudster would be trying to maximize the value of each stolen cc they have on hand. When you have a system that doesn't tell the fraudster what is causing the stolen cc to be rejected, the fraudster has nothing but trial&error to improve their chance, maybe instead of public wifi they have to use a private one, maybe instead of a gmail account they have to use a edu account. But in this case, if they know that a embossing kit will significantly improve their chance, wouldn't they spend the money and get that technology?

The bottom line is this technology has to make it more expensive for the fraudster to throw their hands up and say "well i better go try a different place". but I'm not sure if the barrier is high enough here. Furthermore, if you have an 'invisible' barrier, then it is all about trial and error, if you have a 'visible' barrier, I think it is just going to garner more attention and more people trying to solve it?

So actually acquiring stolen cc numbers is very easy - there's a bunch of marketplaces that sell thousands of them. Figuring out a scalable way to extract value out of them, however, is hard. More than visible or invisible barriers, what makes a fraudster want to spend time getting around the defenses of a specific business is the value of the offering (e.g., banks vs an app that sells a service)

Is there an issue with keeping up with different credit cards that get created as CC companies try to create new products (i.e. do you have classifers for “realness” that do not require staying exactly on top of trends in CC design?)?

For the most part the model should generalize pretty well to new formats, but we do constantly monitor and update to catch up with any holes.

This is inspiring! For a new grad going to a unicorn, what would you recommend as far as types of teams that would teach me skills that help me build my own startup?

Definitely take the below with a grain of salt - this worked for me thus far but there are probably paths other people have taken that worked equally well or better :) My recommendation would be: 1) A smaller/less established team where you'll be responsible for building out key chunks of the team 2) A team where you can build expertise in a domain you find interesting, and where you think there might be more problems than solutions

The benefit of working on a smaller/less established team is getting the autonomy to build something that's immediately impactful to the company and its customers, while not having to worry too about how to stay alive (fundraising, revenue, resources) - I think that's pretty good training for building a startup.

Picking a team where you'll get expertise in a newer/growing field can be helpful too - think something where you'll only need a few years to become an expert and start adding value. Also be sure to pick something you like, since if you do start a company in that field, you'll likely be spending a big chunk of your life on it.

Thanks so much for the reply! I’ll use this as I go forward to hopefully make the right decisions. I wish you the best of luck with your venture, it’s an amazing idea and I believe in you both :)

Hope it helps - good luck!!!

What happens if a user's card can't be scanned? For instance, bad lighting conditions, or an unusual card format?

Great question! The small proportion of cards that can't be scanned can be pushed through a higher friction fraud prevention flow. Since card scanning is low friction, this allows you to catch a ton of fraud at minimal impact to good users, and subject only a very small number to the higher friction flow.

Congratulations! Been looking for EXACTLY this for our app.

Thanks! Just sent you an email :)

Are those real cards in the video!? Cool product btw.

Hahahaha they're all cancelled or expired cards :)

i like the idea, but what happen with the web sites or your produc only works for moviles?.

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.

Very cool idea and well executed.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact