One Student, Four Jurisdictions: The Hardest Data Problem in Software Is a Person Who Moves

~ Mr Sanjay Laul, Founder, MSM Aventra

Picture a single student’s file today. She applies to a university from Lagos, through an agent whose CRM sits on servers in the UK. She enrolls at a branch campus in India, where her academic record becomes subject to that country’s data protection law the moment it is created. Two semesters in, she transfers into a joint degree arrangement with a partner institution in Germany, and a portion of her transcript now legally exists under GDPR. She graduates, and an employer in the UAE needs to verify her credential, triggering a fourth jurisdiction’s expectations about how that verification should happen and what can legally be disclosed in the process.

Nothing about this student is unusual anymore. Transnational education, branch campuses, joint and dual degrees, and remote and hybrid delivery have made exactly this kind of multi-jurisdiction academic journey close to routine. What has not caught up is the software architecture meant to represent her as a single, coherent person.

The record is not the same as the person, and the law insists on that difference

Most enterprise software treats a “single customer view” as a data engineering problem: deduplicate records, reconcile identifiers, build one clean profile. Higher education’s version of this problem looks similar on a whiteboard and is genuinely much harder in practice, because the law does not allow the record to simply exist wherever the architecture finds convenient.

Under FERPA in the United States, an education record is subject to specific disclosure rules the moment an institution receiving US federal funds creates it. Under GDPR, the same category of information, once it touches an EU resident or is processed by an EU-based entity, carries a different legal basis for processing, a different consent framework, and enforceable rights including erasure and portability that FERPA does not grant in the same form. Brazil’s LGPD mirrors much of GDPR’s logic but is its own regime with its own enforcement posture. Data residency and sovereignty rules in several other jurisdictions go further still, treating the physical location of storage as a compliance question in its own right, not merely an infrastructure decision.

This means a single human being, moving through a single academic journey, can generate a data record that is legally required to behave like four separate records, each governed by different rules about who can see it, how long it must be kept, and whether it can be deleted on request. A software system built around the assumption that “the student” is one row in one table is architecturally incompatible with that reality from the outset.

Where the conflicts actually bite: retention, consent, and erasure

The most concrete version of this problem shows up in a direct conflict most institutions have not fully reckoned with. GDPR grants a right to erasure. Academic accreditation frameworks, in many countries, require institutions to retain transcript and assessment records for a fixed, often lengthy period, specifically so a credential remains verifiable years later. When a student’s record spans both regimes, an erasure request under one jurisdiction can collide directly with a retention obligation under another, for the same underlying data describing the same person’s academic history.

Consent architecture creates a parallel problem. A CRM capturing a prospective student’s data in the recruitment phase typically operates on a marketing consent basis. Once that same person enrols, the legal basis for holding their data shifts, often to legitimate educational interest or statutory obligation, under an entirely different framework depending on where enrolment happens. A system that cannot track which legal basis applies to which slice of a student’s data, at which point in their journey, and update that basis automatically as the student’s status changes, is not simply behind on documentation. It is exposed to genuine regulatory risk, and its owners frequently do not discover this until an audit or a subject access request forces the question.

Cross-border transfer mechanisms add a third layer. Moving a student’s academic data from a host country back to a partner institution for a joint degree, or from an admissions system in one region into a student information system in another, is not just an API call. Depending on the jurisdictions involved, it may require Standard Contractual Clauses, a documented transfer impact assessment, or a formally recognised adequacy decision before the transfer is even lawful, regardless of how technically trivial the data movement itself would be.

Why this is an architecture problem, not a paperwork problem

The instinct inside most institutions is to treat this as a compliance function, something layered on top of the software after the fact, handled through policy documents and manual review. That instinct does not survive contact with the actual data flows. A student’s record is being written to, read from, and transferred between systems continuously across her academic lifecycle, from her first enquiry through to her final credential verification. Compliance cannot be bolted onto that flow after the architecture is built. It has to be a property of the data model itself: which jurisdiction’s rules apply to this specific field, at this specific point in the student’s journey, and what happens automatically when that changes.

The technically honest framing is this: the hardest part of representing an international student in software is not identity resolution or deduplication, the problems most platforms are built to solve. It is designing a data model expressive enough to represent one continuous human journey while correctly, automatically, and defensibly treating different slices of that journey as legally distinct records, each governed by rules the student herself never chose and the institution cannot negotiate away.

Global academic mobility is no longer the edge case a system can patch around later. It is quickly becoming the default case education software needs to be built for from the first schema decision onward.