Overview

InCountry provides a variety of encryption, tokenization, hashing, and pseudonymization capabilities that are specified at the field level. Tokenization can be deterministic, where the same token is generated every time for a specific origin value. Pseudonymization features include modifying numerical values and flexible data masking using regular expressions.

While InCountry manages the application’s regulated data for a particular country, the source application continues to provide user authentication and authorizes all actions and data access. The source application and identity provider specify what countries a user can access and continue to provide Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Policy-Based Access Control (PBAC). Using the existing user model is critical as it can be very difficult to replicate and maintain cloned access policies, especially for applications with fine-grained access controls.

For highly regulated environments, user, employee, and customer PII can be managed within InCountry and the global Identity Provider contains masked user names and e-mail addresses.

InCountry can match your existing web services search endpoint, and then perform the search locally within the InCountry Vault. The data stored within a country can also be extended with unregulated data that is replicated in order to perform more efficient searches. For example, if First Name and Last Name are regulated and stored within a country, but City is not, InCountry can still perform a search for Last Name = “Han” and City = “Beijing”.

The proposed results are then authorized by your application to ensure that the current user is authorized to view the records and the individual fields within each record. The results are then returned using the same JSON format your existing search web service uses to return search results.

InCountry provides serverless functions so that code can be executed on regulated data. Use cases include validating values and performing calculations. The code execution is fully sandboxed and isolated to prevent data loss. Currently, InCountry functions support JavaScript, and existing code can be easily translated using AI code transformation.

InCountry’s e-mail service makes is possible to run global applications that do not have visibility into user e-mail addresses, names and other PII. The InCountry e-mail server can redact and unredact sensitive data from both outbound and inbound e-mails.

For outbound e-mails, e-mails with hashed e-mail addresses are sent to the InCountry SMTP with the target country, where actual e-mail addresses and other PII are inserted into the e-mail, and then it is sent on within the country. For inbound emails, the service captures e-mails and can redacts e-mail addresses and other PII and replaces the values with hashed values, so regulated data does not leave a country.

InCountry provides two reporting use cases. Reporting of detailed regulated data within a country, and reporting of aggregated and anonymized data outside a country.

Detailed reporting within a country can combine regulated data and unregulated data, with filtering, grouping, and aggregation. Your application can continue to provide drill down functionality and users can use data they are authorized to see. For example, a Sales Manager can see the total pipeline amount by city and drill down and see each prospect.

Aggregate reporting outside a country uses InCountry’s aggregation functions so that reports running outside a country can provide aggregates of regulated data. For example, a Sales Manager can see the total pipeline amount by city, but can not drill down and see each prospect.

The InCountry Files service supports small files <15MB as standard HTTP attachments and large files with a REST API similar to S3. Files must be attached to a primary record in order to prevent orphaned data and support compliance requests.

The InCountry Payments service is a fully PCI DSS compliant solution that is fully localized in each country and can work with a different designated payment processor for each country. Your application does not need to attain PCI DSS compliance but can still maintain independence from payment processors and switch processors as needed by business requirements, without disrupting customer saved credit card numbers or recurring payments.

Data from InCountry vaults in multiple countries can be fed into a single global LLM using field-level anonymization techniques. Data fields like first and last names can be anonymized, and the LLM subsequently tokenizes the anonymized data. The LLM can then perform on a global data set, and LLM users do not have visibility into regulated data fields.
For AI insights operating directly on local data in a country, an LLM can be deployed fully within a country as a container and integrates data directly from the InCountry Vault in each country. To maintain data loss prevention in each country, the data fed into the LLM can be masked, or the container can be purged after performing its duties.