A dashboard can create a cross-border data transfer even when nobody downloads a file. If a Berlin support team can view payment records held for a Ghanaian fintech, the access itself may expose regulated data across jurisdictions and trigger obligations the product team never designed for.
In 2013, Austrian privacy advocate Max Schrems filed a complaint about Facebook transferring personal data from Europe to the United States. The arrangement relied on Safe Harbor, a framework thousands of companies treated as settled infrastructure. Schrems challenged whether that protection held once the data reached a country where public authorities could access it.
The question eventually reached the Court of Justice of the European Union in Luxembourg. In 2015, the court invalidated Safe Harbor. Five years later, in the case now known as Schrems II, it invalidated its replacement, the EU-US Privacy Shield.
The Court’s 2020 judgment left companies with a harder question than where their servers sat. They also had to consider who could access the data, under which country’s laws, and whether the safeguards surrounding that access provided adequate protection.
The transfer happened through a screen
The Ghanaian fintech founder encountered a smaller version of that problem on a Tuesday during an audit.
His team had built a support dashboard so colleagues in Berlin could investigate failed payments. The dashboard displayed customer names, transaction references, payment status and notes from earlier support conversations. Berlin needed the view because some partnership and support work happened there.
Nobody had emailed a spreadsheet. Nobody had copied a database into a shared drive. The production system remained where the engineering team expected it to remain.
That made the first internal answer sound reasonable: no data had moved.
The auditor’s next questions changed the shape of the discussion. Who could open an individual record from Berlin? Could they search by customer name? Did the browser receive the underlying fields? Were those views logged? Could a support agent copy the information into a ticket or take a screenshot?
A database can stay in one country while personal data becomes available in another. A support interface may therefore create the same governance problem as an export, even though the product team never built an “Export” button.
The lesson from Schrems applies directly here. Data location answers only one part of the question. Access location, legal jurisdiction, purpose and protection matter too.
Product permissions become compliance decisions
Early fintech teams often treat support permissions as an operational detail. Someone needs to resolve a payment issue, so an engineer adds a role, hides a few fields and ships the dashboard.
That decision sets policy in code.
The role determines which people can see payment records. The query determines which fields cross the network. Logging determines whether the company can later explain who viewed a customer’s information. Retention settings determine how long copied details remain in support tools.
This is close to the problem I described in the shared spreadsheet the demo did not account for. The visible workflow can look controlled while a second, informal data path carries the real risk.
The useful response is not to disable every remote account before understanding the facts. First map the access path. Record the data categories shown, the people and locations with access, the reason they need it, the systems receiving it and the safeguards around each step. Then put that map in front of qualified privacy counsel or the responsible compliance lead.
The answer may differ depending on the customers, payment partners, contracts and jurisdictions involved. The engineering facts still come first. A lawyer cannot assess a data flow that the product team describes as “the dashboard shows some payment information.”
Reduce the view before defending it
The fastest practical improvement is often a smaller support view.
A Berlin agent investigating a failed transaction may need a reference, timestamp, status and error category. They may not need the customer’s full name, complete payment history or free-text notes. Masking fields, restricting searches and separating routine support from exceptional access can reduce exposure without stopping the team’s work.
Exceptional access should leave evidence. If a colleague must reveal a protected field, the system can require a reason and record the event. That does not settle the legal question, but it gives the company something concrete to assess and audit.
Teams should also test the permissions themselves. Role names such as “support” or “viewer” reveal little. Log in as that role from the relevant environment, inspect the network response and confirm what the browser actually receives. A field hidden with CSS is still data delivered to the user.
The same permission discipline matters when software acts for a person. In why Mensah needed a failed purchase as proof, the useful evidence came from testing what the system could still do after access should have ended.
Treat geography as part of the architecture
Schrems began with a complaint about one company’s transfers. By 2020, the resulting judgment had removed a framework used across the Atlantic. The uncertainty mattered because firms had built ordinary operations on an assumption that access and transfer questions were already handled.
A Ghanaian fintech working with people in Berlin, London, Lagos or San Francisco cannot afford that assumption. Geography enters the product through staff accounts, support vendors, analytics tools, logs and browser sessions, long before anyone selects “Download CSV.”
Before the next audit, open the dashboard’s permission matrix and add two columns: where each role can be used, and which customer fields the role can retrieve. That small document will expose more than another general promise that customer data stays secure.
Comments
No comments yet.