Out of Bounds, Out of System: The Tragedy of Being an International Student on the Greek Web
Current Session Stats
I successfully finished my first year at the Hellenic Open University (EAP), surviving ANSI C pointers written on physical paper and fast-paced Python oral examinations. With a passing grade in my pocket and a smile full of academic optimism, I logged into the portal today to declare my courses for the second year. Everything was going smoothly, until it was time to fill in my personal details.
At that moment, the system decided to remind me of a harsh reality: on a Greek academic web portal, if you live abroad, you simply do not exist. Instead of acting as a student helper, facilitating processes, the platform turns into a digital labyrinth that forces you to invent workarounds to bypass its own obstacles. It is one of those implementations that acts as the ultimate anti-pattern: it makes you think, "What should I NEVER do in my own work as a future developer?"
I honestly wonder: if the developer of this system submitted this digital joke as a semester project at EAP, what grade would they get? They would probably be sent packing to re-register next year with a grand 0/10 and a note pointing out a "complete lack of algorithmic thinking." It is highly ironic: they put us through a sieve for 6 ECTS, demanding enterprise-grade, modular, and testable architectures. Yet, on the institution's official portal, the professionals who are actually paid to write code deploy stuff that looks like it was generated by Llama-3.2-1B with 2-bit quantization (and no system prompt), ignoring basic web development rules and violating EU regulations.
Chapter 1: The Art of if (iban.length != 27) return false;
The first major slap in the face came with the payment method. As a student living and working permanently in Germany, I have a German bank account. Naturally, I went to register my IBAN.
For those who don't know, since 2012 and the implementation of SEPA (Single Euro Payments Area) under EU Regulation 260/2012, all EU countries are legally obligated to accept IBANs from any member state. So-called IBAN Discrimination (rejecting foreign IBANs) is illegal.
But the "vibe coder" (hopefully just a vibe coder and not a certified HTML expert) who wrote the validation script had a different opinion:
// A likely depiction of the architectural genius behind the system
function validateIBAN(iban) {
// Because who on earth would have an account outside of Greece? ¯\_(ツ)_/¯
if (iban.length !== 27) {
showValidationError("IBAN must be exactly 27 characters!");
return false;
}
return true;
}Greece has a 27-character IBAN. Germany has 22 characters. The EAP system, doing a simple and dry string length validation, decided that Germany does not meet its specifications.
A proper developer who respects their keyboard would use an existing validation library, or at least a dynamic check that reads the first two letters of the country (e.g., DE, GR, FR) and verifies the length against the ISO standards table.
And more importantly? They would implement the actual check digit validation: Modulo 97.
For the EAP "whiz kids" who might be reading this article and wondering how the ISO 13616 algorithm works —which, by the way, is taught in introductory programming courses— the process is extremely simple:
- Take the first 4 characters of the IBAN (e.g.,
GR24orDE21) and move them to the end of the string. - Convert the letters to numbers (
A = 10,B = 11, ...,Z = 35), creating a massive integer. - Divide this number by 97. If the remainder (modulo) is exactly 1, the IBAN is valid. If not, a typo has occurred.
But the EAP developer preferred to play with string lengths. This means that if you type a Greek IBAN with 27 characters that contains typos (e.g., writing 5 instead of 6), the platform will happily accept it! Their validation is completely hollow, even for Greek students, simply because they were too lazy to write 5 lines of code to check the checksum.
Instead, we find ourselves in 2026, and the EAP system enforces digital borders, forcing students to commit "minor illegalities" (like borrowing IBANs from friends or relatives, only to potentially cause tax office headaches for everyone involved) just to proceed with the registration.
Chapter 2: The Geographical Matrix (Germany, Prefecture... of Attica?)
Having bypassed the shock of the IBAN, I proceeded to the residential address. I select my country: Germany.
In any normal UI, selecting a country outside of Greece would trigger an event that either changes the address fields, makes them free-text, or disables the dropdowns that only apply to Greece.
Not here. At EAP, selecting a "Prefecture" (county) is a required field. And the only options in the dropdown? Attica, Thessaloniki, Achaea...
According to the university's database, the city of Stuttgart officially belongs to the Prefecture of Attica (or maybe the Cyclades, if you prefer an exotic destination).
Spitting a little technical fire: Probably their front-end doesn't support events like onchange. Or maybe the code is such spaghetti / AI slop that if they disable the Prefecture field, a null pointer exception will throw on the backend, crashing the entire database server.
In the end, I just said: "Yeah, sure, I live in Attica, right in Kifisia," and put in whatever, just so they don't think we're poor.
Chapter 3: Landline Phone Nostalgia
The cherry on top came with the contact details. The system requires a landline phone number.
First of all, in 2026, most of us don't even have a landline phone line at home. We use mobile phones and VoIP services exclusively.
Additionally, the landline field does not accept country codes outside Greece (+30) or even area codes outside Greece. I might not have a landline, but if I were a German citizen with a foreign landline (+49...), the validation hits red.
Most likely, the validation module was written during the dial-up modem era, when internet was charged by the minute and the landline was the block interface of the family. I expect that in the next step, they will ask me for a Telex number, a Fax, or a telegraph address to send me my exam results.
Conclusion: Rules for thee, but not for me
The irony is thick and borders on the absurd. Absolute academic consistency is demanded of us students. We must understand in depth the importance of correct error handling, edge-case validation, data security, and compliance with international standards. If we submit code with a single unhandled exception or forget to validate user input, the professor (our own "Plato") will cut us down in the presentation, sending us to re-register next year with a note that we are "not ready for production."
Yet, when the institution itself goes to production, these rules vanish into thin air. Laziness in code is baptized as a "system," European regulations (SEPA) are blatantly ignored, and the user/student is forced to act as an "alchemist" to bypass their bugs.
And this isn't just about bad UX. We are talking about real-world, material consequences. When you force an international student to borrow a Greek IBAN from a friend or relative to complete their registration, you push them into a gray area that could cause tax office or banking issues down the road (proof of funds, capital transfers, etc.). All because a developer was too lazy to write 5 lines of dynamic checks.
Dear EAP, academic institutions should teach the technology of the future, not maintain 90s digital museums that harass their students and violate European directives.
If maintaining the portal is so difficult, we have a proposal: Assign the portal platform to us as a semester project for PLH. We promise to deliver it modular, responsive, with dynamic validation, fully SEPA-compliant, and above all, without Stuttgart having to move to the Prefecture of Attica for someone to get their degree.
It is time for a serious refactor. Because the portal's UX is not just bad; it is insulting to a community that is supposed to be studying and learning Computer Science. And as for IBAN Discrimination? When the law prescribes hefty fines (even €500 for each individual case of a rejected payment due to a different format), this amateurish implementation in production is not just an innocent bug. It is a financial and legal time bomb ready to explode.
Refactor now.