Robotic Process Automation, or RPA, is a rapidly evolving space expected to grow at more than 32 percent a year through 2028. By combining intelligent software robotics with easy-to-use no-code interfaces, a handful of tightly designed RPA workflows can do the job of an entire department by navigating to websites, filling out forms, and clicking buttons without human intervention. It promises to disrupt back-of-house operations at companies in every industry.
But to do so, RPAs will inevitably have to touch sensitive data. For example, RPA workflows designed to automate invoicing hundreds of vendors or process thousands of insurance claims will rely on high-value data, like social security numbers, bank account numbers, birthdates, usernames and passwords, card numbers, and so on. Storing and using data in plaintext exposes regulatory violations and data breaches. So creating an RPA that leaves sensitive data unsecured isn’t an option.
Let's take a look at how one company partners with Basis Theory to help its customers obscure sensitive data from their RPA workflows.
How can RPAs pass data securely?
Generally speaking, there are two primary ways of securing sensitive data at rest for use between systems: encryption and tokenization. While encryption is computed from the original value, tokenization creates a reference (or token) to the sensitive data. Unlike most encryption methods, tokens can preserve a familiar format of the underlying value. This helps a masked value token, like 975hJDK@zmail.com, pass a forms’ data validation where the encrypted value, Tg2Nn7wUZOQ6Xc+1lenkZTQ9ZDf9a2/RBRiqJBCIX6o, will be flagged as an “invalid email address.”
Let’s take a look at this in action. For this example, we’ll look at Weeldi, a no-code RPA platform. Weeldi’s customers can use Basis Theory to secure and tokenize their sensitive data within the workflows they design.
Designing the workflow
Say a business wants to automate payments to a Telecom Provider, like Verizon, on behalf of its customers. The RPA solution would need to supply the Telco’s website with the individual credentials to 1) log-in and 2) a card on file to submit payment. In this case, Weeldi doesn’t want to store that sensitive data itself. This would require the platform to build out its own tokenization platform and assume liability or obligations associated with the original data (e.g., credentials and card numbers). So it relies on a third-party vault that stores tokenized data.
First, Weeldi customers standardize the naming conventions in Basis Theory for the common sensitive Input Values they’ll be using for their automated workflow, called a Template. Input Values are typically items like Passwords, Account numbers, Credit Card numbers, and Personally Identifiable Information (PII).
Then the customer records the automation Template by manually walking through the traditional workflow in Weeldi as if they were normally doing it. They’ll also take this opportunity to correlate the sensitive Input Values to the identical Basis Theory values previously mentioned.
Running the workflow
When the Job is run, it doesn’t inject the login form with raw usernames and passwords. Instead, the Job inserts the token corresponding to that data encrypted in the RPA’s tokenization platform. The Job then uses those tokens to retrieve that plaintext data from the vault, and enter them in the login fields. The same magic is used for submitting card numbers into the Telcos payment form.
Final thoughts
The actual value of RPAs lies in the ability for anyone to create their own RPA flow. It’s why no-code solutions, like Weeldi, are so valuable. For companies wanting to employ RPAs, building an in-house solution comes with drawbacks. First, you’ll have to create an API to interact with the RPA platform itself, which suddenly renders a no-code solution into anything but. Second, you run the risk of consuming the cost you’d hoped to gain with RPA in the first place.
If you decide to build an RPA solution in-house and your workflow requires sensitive data, here are some criteria to consider when choosing your platform:
- Lets you leave: Third-party providers shouldn’t make switching a battle. Avoid tokenization platforms that lock customers in.
- Pricing that scales with you: Costs should be proportionate with usage and company size. Even though the option to move providers should always be available, you ideally want to choose one for the long haul and whose prices are responsive to circumstances.
- Data governance controls and tools: Your platform should allow you to assign granular levels of classification and impacts on the data. This provides applications greater flexibility in permissions and controlling access.
- Easy to integrate: Third-party providers shouldn’t limit the rest of your stack. A good platform should be easy to use both with other apps, and with as many different frameworks as possible.
Weeldi x Basis Theory: Secure, easy-to-build automation
Shameless plug, but if you’re designing RPAs that handle sensitive data or require bots to login with authentication credentials, try Weeldi and its integration of Basis Theory.
