How do you give a vendor realistic test data without the real customer values?

A bank is replacing its loan system, and an outside team tests the new one. The system checks that an ID number has a set length, that an account number follows a set pattern and that a name field is not empty. Invented values fail those checks, and building a realistic set by hand takes weeks.

So the team asks for an extract of real customers. A few hundred thousand rows are prepared with names, ID numbers and account numbers in them, and sent by secure transfer.

The team needs the shape of the data more than the values, but the only realistic file they can get is the real one. The extract then sits in test environments, on laptops and in shared folders, which are looser than production.

It is kept after the testing ends, and you cannot see who opened it.

Real customer identity data sits in places that were not built to hold it. A breach of a test environment is still a breach of customer data, and you may have to report it. The data also stays in use after the project ends, with no record of who read it.

Inventing data by hand takes weeks and misses cases that real data would show. Replacing the values with random text fails the same format checks that invented data does. A deletion clause with a signed confirmation gives you a statement and no way to check it is true.

You choose the sensitive columns for the test team’s view: names, ID numbers and account numbers. Each is sealed, which replaces the value in place with an encrypted token. With the format kept, the token has the same length and character type as the original, so the system’s format checks still pass. The file keeps its shape, column order and row count, so the team tests against data that behaves like the real thing.

The team opens the file in its own tools and works with the other columns, and never reads the sealed ones. A holder of the licence can unseal the values, and a vendor without it cannot. A column the team does not need at all can be left out of the file instead.

The team has its own licence with an end date. When testing ends, you end the licence and NakodaX stops releasing the key. Every read is recorded. NakodaX does not store the data: it moves from your systems to the team’s.

Sealing with the format kept runs through the Python library, so check that your pipeline can use it. A team that already opened a file keeps what it opened, and ending the licence does not reach it. You choose which columns to seal, and NakodaX does not check whether the remaining columns could identify a person. The team needs a licence key and the NakodaX library, or the reader in the console.