IBAN support for no-code platforms
International Bank Account Numbers and data type design decisions 2021-10-19 #NoCode
International Bank Account Numbers (IBAN) standardise bank account identifiers. Like other so-called numbers, an IBAN has a specific structure that includes a two-letter country code and check digits that mitigate transcription errors.
Business software commonly includes standardised data, such as IBANs, that facilitate international commerce. These standardised data formats allow for special handling, for input, validation and formatting.
Traditional business software development
When software developers build business software, a lot of effort goes into handling data such as bank account numbers. To mitigate the cost of errors, software user interfaces can guide user input, check for certain kinds of input errors, and format values in helpful ways. While an IBAN consists of letters and digits, conceptually, we usually read them in groups of four characters separated by spaces, because that makes them easier to transcribe correctly. The IBAN standard also includes an algorithm for verifying the check digits.
GB98 MIDL 0700 9312 3456 78
Writing code to handle input, validation and formatting for specific data types requires significant software development effort. It also involves complexity that leads to extra time for testing and fixing bugs. Professional developers turn to open-source libraries for these specifics, such as iban4j and java-iban, so they don’t have to become IBAN experts and implement the algorithms themselves (and then fix the inevitable bugs).
No-code automation
People using no-code automation platforms have the same challenge when working with specialised data such as IBANs. However, those no-code platforms don’t generally support custom behaviour, such as IBAN input guidance, validation and formatting.
From the perspective of the people building the no-code platforms themselves, this scenario introduces a tough design decision. No-code automation has to choose from the following options.
Basic data types
Just because you could probably build IBAN validation in a Notion formula, doesn’t mean you should. Meanwhile, builders have to get by treating IBAN as text, and don’t get the user interface that online banking offers, at eye-wateringly high development costs when compared to a no-code solution. No-code platforms can make this trade-off, and accept a basic user experience and data integrity challenges, and benefit from a simpler builder experience.
Industry-specific data types
For some applications, no-code builders won’t accept the compromises that come from treating IBANs like other kinds of text, and platform vendors will add support. However, they probably can’t add support for every kind of standardised data, such as EAN codes, IMEI, Incoterms and ISBN. No-code platforms may focus on a specific industry vertical, such as banking and finance, and support that domain’s specialised data types, such as IBAN.
Extensible data types
Extensible no-code platforms don’t accept the limitations of simplification or industry focus, and could allow their customers or partners to develop custom data types. Vendors might make the platform extensible enough to allow pluggable data types that provide their own input user interface, data validation and formatting. Whether or when this happens matters less than the fact that it could: no-code limitations’ belong to the current state of the art, not to the future.
