Will My RPA Robot Get Blocked?  No, if used responsibly.

Will you get blocked if you use RPA?

The answer is: no, you will not get blocked, if you use RPA responsibly. 

This is a common question at the start of an RPA journey: "will our 3rd party vendors allow us to use robots on their site?" 

The good news is that most companies/vendors expect and know about robot traffic on their sites.  In fact, some government agencies, like IRS.gov give outright permission to use RPA.

Companies expect bots to use their sites

It's an IT industry assumption that bots are used and allowed across the web.  

• For example, Google Analytics (which reports on a business's website traffic), will  differentiate bot traffic from human traffic.  In other words, bot traffic is so prevalent, it can even be as common as human traffic.

The exception is if a vendor website specifically states in it's Terms of Service "don't use a bot".  In such cases, that's usually because they provide has API-for-a-fee that they prefer you use.  

• For example, Zillow.com does not allow bots, because they sell API access instead. 
• Most vendor websites in healthcare do not have an API, so this point is not relevant.
• Even if they state they do not allow bots, see the section below on "What to do if a vendor/company is uncomfortable with your RPA bots on their site?"

How companies monitor responsible bot usage on their sites

Because almost all companies expect bot traffic, they simply monitor traffic and temporarily suspend your access via your IP if you over-burden their system.  They unblock your IP after some time pre-determined time passes, and then you can resume activity.

US Government sites

US Government websites seem to follow the trend among commercial companies/vendors, in that they expect bot traffic, and just protect themselves against being overburdened.

• For example, my colleagues got permission from IRS.gov to use bots on the IRS site.  
• The Developers just had to follow acceptable usage patterns on the IRS site.  For example, they are allowed to robotically enter information into a series of IRS.gov online forms.  To mimic human behavior they must complete all the online forms that a human would to finish the application.  
• They are not allowed to simply retry one page of a form over and over.  For example, they cannot enter the name and SSN of a person on the first page of the application, and then try that again repeatedly.  This is because it looks like the bot is trying to guess SSN numbers (using "brute force" guessing method).  
• Even if the bot attempts this at high speed, the bots IP address is only blocked for 20 minutes by IRS.gov, and then they can start again.
• The same velocity threshold settings are used in payment gateways which we use (like Authorize.net, USAePay.com).  
• For example, when AR Proactive received unwanted bot behavior (of rogue developers trying to guess credit card numbers, for example) we put a velocity setting in place to block them for 30 minutes.

Additionally, it's possible that US Government websites actually welcome RPA initiatives.  And possibly this would include Medicare (on the federal level) and Medicaid (at the state level).

• For example, the U.S. General Services Administration (GSA) is encouraging federal agencies to deploy RPA in their operations to "increase accuracy, compliance ... and organizational capacity". More here at this article: Why Deploy RPA at Your Federal Agency?  
• The US Treasury is interested in learning about banks use of Artificial Intelligence in their operations in this OCC Bulletin.
  
  

What to do if a vendor/company is uncomfortable with your RPA bots on their site?

• Explain what the business goal is.  Companies know there are "good bots" using the site as intended. And there are "bad bots" using the site to exploit some vulnerability.  Explain that yours is a "good bot" fitting the intended use of their site
• Respect the vendor's traffic limits.  Ask your vendors what maximum load or speed they can tolerate from your bots?  Then the Developers insert a pause into the bot to slow it down, so it more closely mimics human traffic and respects the company's traffic limits.  
• Whitelist your IP address.  If the company feels comfortable with your goals and loading of their site, request the company to whitelist the IP address(es) of the bot.
• Use multiple IP address. If the company has limits on much traffic can come from one IP address, then use multiple bots from multiple IP addresses (parallelization) to mimic a group of human users.
• How have they handled request for RPA from other customers?  You're probably not their first customer requesting to interact with their site using RPA.  Ask them to find someone on their team who handled such a request in the past.  You can use that as a precedent for your case.

In summary

• RPA usage is known and expected by almost all website and software vendors.
• Usage of RPA should be done responsibly (i.e. mimic human behavior and not violate the site's Terms of Service) so you're not subject to velocity thresholds.  
• Many public companies use RPA to automate mission-critical processes.  These processes interact with 3rd party websites and applications.