AML Optimization – Do More with Less

With AML fines and regulator demands growing by the day, the stakes for AML teams have never been higher. All signs of potential AML activity have to be monitored, which puts a massive burden on investigation teams. But traditional approaches to AML transaction modeling are rigid, prone to false alarms and missing true incidents of money laundering. AML optimization efforts tend to be expensive and are often manual service engagements.

Unlike entrenched AML transaction monitoring solutions, our solution was built from the ground up to use the power of unsupervised machine learning to drive superior AML optimization. Rules-based and supervised machine learning systems require constant tuning as fraudsters discover new ways to evade them. Every false positive means wasted investigation cycles. Every false negative is an existential risk to your business. The good news is that we can help.

Unsupervised Machine Learning for AML Optimization

Reduced False Positives
deep visibility into subtle relationships that traditional systems miss in exchange for  better efficiency
Reduced False Negatives
we don’t rely on prior knowledge of specific money laundering patterns, increasing effectiveness.
Easy, Automatic Upgrades
modern deployment means you don’t have to deal with painful 3-5 year upgrade cycles. Get the newest capabilities the minute they are ready.
Standalone or Add-on Deployment
no need to replace an existing AML transaction monitoring solution until you are ready


Banking Fraud Prevention

Modern fraudsters are more sophisticated than ever. They’re well-funded, well-educated and well-organized. They go into offices, sit at their desks and get to business.. Make no mistake about it – they take their job seriously, and their job is to steal your customers’ money.

Making matters worse, modern banking systems are exceedingly complex. Our banking fraud prevention systems were built for a simpler time. Reputation lists, rules engines and rudimentary analytics approaches are only good at catching simple fraud that follows predictable patterns. But the modern fraudster is anything but predictable. They test and reverse engineer your fraud prevention defenses, constantly evolving and evading detection. As a result, most current approaches to banking fraud prevention are inherently antiquated.

Unsupervised Analytics: True Prevention

DataVisor is the first company to deploy unsupervised machine learning at a massive scale to help banking fraud prevention teams. Our approach flips the problem on its head – we don’t rely on prior knowledge of attack patterns. By definition, we stay ahead of the fraudsters and help you prevent banking fraud, not just clean up the damage after it happens.

Our approach is:

  • Preventative, not reactive.
  • Easy to deploy.
  • Massively scalable.
  • Broader in scope.
  • Real-time decision friendly.
  • Highly accurate.

How To Register Millions of Fake Accounts With Ease

iPhones Charging


Fake accounts are a bigger problem than ever. With so many new security, why are they still so prevalent? Recent studies show that approximately 10 percent of accounts on social media sites are fake [1,2]. Other reports are more drastic: Instagram’s crackdown on spam fake accounts in December of last year exposed 18.9 million (29 percent) of followers of the Instagram official account as fake [3].

Really, is it that easy to register so many fake accounts? Sounds too good to be true. The reality is that there are many “helper” tools that enable bad actors to evade traditional security measures. Free voicemail services like K7 and Laser Voicemail provide disposable numbers to bypass phone verification. Guerrilla Mail, Mailinator, Fake Mail Generator are just a few of the providers of anonymous, temporary email addresses. Captcha solver services, many manned by human labor in Southeast Asia (see Figure 1), can cost as low as $0.5 for 1000 images. Anonymous proxies, VPNs (e.g., HideMyAss, FilterBypass, ZenMate), and cloud hosting services allow traffic to appear from different locations, defeating blacklisting or IP-based rules.

Workers Distribution by Countries

To make it even easier for attackers, there are all-in-one account creator software that automates all of the above for you, such as the $2,500 (two PC license) deal from, and “click farms” where fake accounts are registered manually and resold for different purposes [4]. Even dedicated hardware, i.e., jailbroken iPhones, have emerged in China. The phone comes complete with not only account creation capabilities for multiple online services (WeChat, Momo, Bilin, iAround, Weju, and Moca), but also automated messaging scripts and IP changer software for $550 – $700. The title image at the top of this post is a screenshot of the jailbroken iPhones being programmed by the seller.

Taobao ad for all-in-one “fraud” phones.

The table below summarizes the security solutions commonly used at online services, and the attack techniques to defeat them.

Security Solution & Attack Techniques Table

Why are fake accounts so attractive? The sophistication of online services today has opened up lucrative opportunities for criminals. As mentioned in our earlier blog post, many service features including social reputation, ad impressions, promotional/reward points, and in-game virtual items can be converted into real-world gains. If account creation software alone costs $2,500, the profit that can be milked out of the fake accounts must be many, many times greater – at the cost of the online service.
[1] Emil Protalinski. “Facebook estimates that between 5.5% and 11.2% of accounts are fake.” The Next Web 3 Feb 2014.
[2] Lara O’Reilly. “8% of Instagram accounts are fakes and 30% are inactive, study says.” Business Insider< 2 Jul 2015.
[3] Vindu Goel. “Millions of fake Instagram users disappear in purge.” The New York Times 18 Dec. 2014.
[4] Doug Bock Clart. “How click farms have inflated social media currency.” New Republic 20 Apr. 2015.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Medication Identifiers and How to Check for Potential Problems

Let’s take a look at the various identifiers in this post. We’ll also review how you can use that data to check for related warning & alerts using the PillFill API services.

Prescription Structure

Let’s begin by looking at an example of a prescription collected by the PillFill RX aggregator (with some fields omitted):

  "rxNumber": "995575",
  "medicationName": "OMEPRAZOLE DR 40 MG CAPSULE",
  "pharmacyStoreId": "CVS #1183",
  "daysSupply": 30,
  "quantityRemaining": 30,
  "dispenseDate": "2014-04-30",
  "computedInactiveAfterDate": "2013-04-29",
  "previousDispenseDates": [
  "brandNames": [
       "Prilosec 40 MG Delayed Release Oral Capsule"
   "quantity": "30",
   "ndc": "00378522293",
   "rxNormId": "200329",
   "ndfrtNui": "N0000156769",
   "ndfrtName": "OMEPRAZOLE 40MG CAP,SA",
   "splId": "44260509-A91C-4906-BCC7-4EB5D3465DED",
   "uuid": "00153170CDEC5571782287505711C59EB63C",

The three most important identifiers included in the prescription data are:

  • The FDA’s National Drug Code (ndc)
  • The FDA’s Structured Product Label (splId)
  • NIH’s RxNorm ID (RxNormId)

We also make liberal use of:

  • The VA’s National Drug File Reference Terminology ID (NUI)
  • The FDA’s UNique Ingredient Identifier (UNII)

Identifier Relationships

The natural question to ask at this point is “Why so many identifiers?” Each identification system provides different levels of understanding to what the medication actually is — a question that can be surprisingly hard to answer at times. Let’s consider Ibuprofen as an example- we have to consider it from multiple perspectives:

  • Drug Ingredients: Which drugs are included / what are the active ingredients? (e.g. Ibuprofen, Acetaminophen & Caffeine)
  • Drug Concept: What’s the strength & form of the drug? (e.g. 200mg Ibuprofen pill, 500mg Acetaminophen pill)
  • Drug Package: How is the drug packaged or group together? Who manufactured it? (e.g. Equate 500ct Ibuprofen, Equate 200ct Ibuprofen 2-Pack, Equate 12ct Ibuprofen Convenience Pack)
  • Drug Product: Which one of the specific drug packages did the patient receive? (Equate 12ct Ibuprofen Convenience Pack)

Each of the above identifiers can help answer those questions:



A very general hierarchy for OTC Ibuprofen (slightly different for RX drugs)

  • Ingredient = UNique Ingredient Identifier (UNII)
  • Concept = RxNorm ID
  • Package = Structured Product Label (SPL)
  • Product = National Drug Code (NDC)

Like with most hierarchal relationships, it’s important for accuracy to start with the most specific identifier available when trying to figure out where something belongs. That’s why PillFill focuses on gathering NDCs whenever possible, since all other relationships can be easily and accurately derived from there. If the NDC is not available, PillFill will associate at least RxNorm/NDFRT identifiers for each prescription.

Medication Warnings & Alerts

So now that we have a working understanding of the medication identifiers, how can we use them to check for potential problems and gain additional insights?

FDA Recalls & Shortage Alerts

The FDA issues recall & shortage alerts primarily based on NDCs. PillFill provides a RESTFul service for checking for such alerts. It’s as simple as you might hope- a HTTP GET call to an endpoint with the 11-Digit NDC from the prescription:

If the drug is found to have any alerts, you’ll get them back in the result set:

	"ndc": ["00603388821"], 
	"type": "recall", 
	"reason": [ "Qualitest Issues Voluntary, Nationwide Recall for One Lot of Hydrocodone Bitartrate and Acetaminophen Tablets, USP 10 mg/500 mg Due to the Potential for Oversized Tablets" ], 
	"resolution": [], 
	"additionalInfoUrl":  ""

Drug Ingredient Overdose Warnings

The FDA has published a Maximum Recommended Therapeutic Dose (MRTD) guideline which identifies the maximum amount of each drug ingredient is considered safe based on the weight of the individual (using mg/kg). PillFill offers another RESTFul service to handle these calculations for solid oral (pill-based) medications:…&weightInKgs=68

For this service to operate correctly, the prescription must have the SplId available and the quantityPerDose / dosesPerDay fields set for each prescription included. The service will then calculate the ingredient dose levels across all products and provide feedback if the value is over 90% of the MRTD level.

     "unii": "KG60484QX9",
     "ingredientName": "Omeprazole",
     "currentLoad": 91,
     "mrtd": 2,
     "relatedRxs": ["RX-ID_0","RX-ID_1"]

Drug/Drug Interactions

To check for potential drug interactions, we’re going to use a NIH-provided RESTful service. It requires the RxNorm ID of each drug to be considered. Again, it’s a relatively simple RESTful GET request to find potential interactions:

When an interaction is found, a response is generated with some (fairly basic) detail about why the interaction is relevant:

			"name":"Simvastatin 40 MG Oral Tablet [Zocor]","tty":"SBD"
			"name":"bosentan 125 MG Oral Tablet","tty":"SCD"
		"description":"Bosentan may decrease the serum concentration of simvastatin by increasing its metabolism. Monitor for changes in the therapeutic and adverse effects of simvastatin if bosentan is initiated, discontinued or dose changed."
			"name":"Simvastatin 40 MG Oral Tablet [Zocor]",
			"name":"Fluconazole 50 MG Oral Tablet [Diflucan]",
		"description":"Increased risk of myopathy/rhabdomyolysis"


Each identifier is useful in different ways, especially considering each service you’ll want to use will require levels of specificity. Once you understand how each interrelates though, you’ll realize the power associated with each of the different identifier and their terminology/information models.

That said, there are countless other checks you can also preform given the specific information found in the prescription- Ingredient allergies using UNIIs, Drug & Condition/Disease Contraindication Checks, etc. Each can help a patient potentially avoid a serious problem that they otherwise would have never considered otherwise. For PHRs to ever go mainstream, they must and should help to that end. It’s no longer enough to simply track pills.

This is an intervention. Stop storing secrets in your apps.

This is a repost of a submission I made to Reddit’s /r/androiddev subreddit. You can pull up the thread to see the ensuing discussion.

Reading the comments on the cloned app post nearly gave me a nervous breakdown. Fellow devs, please sit down and let’s have a frank conversation about your android app’s security.

It’s time you hear and accept this: Your app doesn’t love you and it will happily betray your trust in the right hands. Don’t believe me? Check out the countless posts from /r/netsec, /r/reverseengineering, /r/pwned about breaking into android apps. A skilled RE (Reverse Engineering) hacker will quickly convince your app to give up all of its closely guarded secrets and do all of those nasty little actions that you took such great pains (and unit tests) to prevent.

Now I know this is hard to hear and I can already anticipate what you’re going to say:

  • But hacking is impossible without access to my apk! Getting access to an apk is simple. Once downloaded to a rooted phone, pulling it via ADB is one adb pull /data/app/[your_apk_name] command away. You can even download an APK from Google Play with the right help.
  • But I used Proguard on my code! Great! Did you include any sensitive URLs, strings, keys, passwords, or other resources in your app? Then you’re still screwed. Proguard only makes your app’s code “harder to reverse engineer”– extracting all of those juicy unprotected strings and resources from your code is still insanely easy. Even modifying a proguard-protected app to bypass a boolean security check is the first thing that you learn to do when patching an app.
  • But I cleverly disguised and encrypted my strings/keys/urls! Do you ever communicate those back to a server? There are plenty of tools that will readily intercept and display any network communication and endpoints- yes, even if it’s SSL/TLS protected. Even if you were careful to never reveal them on the wire, it’s still possible to yank the sensitive bits directly from the memory a running application.
  • But I implemented certificate pinning! That’s a good thing for your users’ security, but it give you no assurances regarding the trustworthiness of your app. Certificate pinning is still easily bypassed if someone intends to do so.

Bottom line: Just like with testing, you should never assume that your mobile app will only operate the way you originally intended it to. Ever. Here are the harsh realities of android development (or any mobile app for that matter):

  • How do I prevent someone from subverting/cloning my app? You can’t. You can make it harder through obfuscation, indirection, etc. In most cases it’ll only provide an annoyance and delay to a determined reverse engineer- a scenario that you absolutely will encounter if your app is at all successful. Also remember that each deterrent you bake makes your app more difficult to manage and is another opportunity to anger an otherwise legitimate user when something goes wrong. Even for companies like Google that do prevent most client-side exploitations, it’s a never ending, incredibly expensive arms race between their vast security teams and individual hackers.
  • How do I perform business-sensitive operations then? If you need to do something that you must be absolutely sure is not subverted, only do them on a server you own and control. This is especially true with any financial transactions, including verification of in-app purchases.
  • But I don’t have the money for a server. Stand up a free AWS instance, heroku dyno, or a $5/month DigitalOcean droplet. If you’re serious enough about your app to try and make money from it, keeping your most sensitive operations on systems you own and control is a simple and cheap safeguard.
  • This all sounds a bit nihilistic. Why do anything then? Realize that there’s two different types of security you should be considering- User Security and Business Security. You should be focused on user security with your mobile apps- it’s about making sure that your users don’t accidentally do anything that would negatively impact them. Things like cert pinning, TLS/SSL, verifying inputs, etc. are all important for user security. But, just like in life, you can’t protect people from hurting themselves or doing bad things. So for your own security, you must always assume that you have malicious users out there (i.e. users of your mobile app) that will lie, cheat, and otherwise ignore all of those virtuous safeguards you put in place for them.

Conclusion – Your app is not your trusted friend. Never included anything in it (e.g. passwords, secret URLs, API keys, etc) that you wouldn’t want someone to see. Securing your app should be about protecting your users’ security and privacy- any sensitive operations or information that you or your business depend on being secret or done absolutely correctly should be handled exclusively on systems you own and control.