Apart from usability and productivity, compliance considerations will increasingly raise the bar on the level of multilingual support demanded from software applications. This trend has already been noticed during implementations of the Single Euro Payments Area (SEPA) regulation among banks and corporations operating in different countries in Europe.
At one such pan-European SEPA implementation, the system landscape was comprised of a payments product processor, a trans-European liquidity manager, a Society for Worldwide Interbank Financial Telecommunication (SWIFT) gateway, and a sanctions-screening product, which was meant to block cross-border fund transfers suspected of having links to terrorism, money laundering, and other nefarious activities.
Since SEPA intrinsically involves cross-border fund transfers, all transactions had to be screened by the sanctions screening application, which would approve a transaction or block it depending upon the outcome of verifications being implemented against various hot lists. Having been built with a fairly sophisticated level of multilingual support this application supported the extended character set of national languages of all the European countries complying with SEPA. Therefore, it was able to handle German umlauts and other accent symbols in various European languages. For example, it could treat the German name "Müller" differently from "Muller", which is derived simplistically and incorrectly by ignoring the umlaut symbol.
Now, since the existing legacy payment product processor did not support an extended character set, there was a strong potential for mismatch between the various systems included in the system landscape whenever a term contained umlauts or other special characters (`, ´, ˚, ˜, etc.) commonly found in non-English European languages.
At one such pan-European SEPA implementation, the system landscape was comprised of a payments product processor, a trans-European liquidity manager, a Society for Worldwide Interbank Financial Telecommunication (SWIFT) gateway, and a sanctions-screening product, which was meant to block cross-border fund transfers suspected of having links to terrorism, money laundering, and other nefarious activities.
Since SEPA intrinsically involves cross-border fund transfers, all transactions had to be screened by the sanctions screening application, which would approve a transaction or block it depending upon the outcome of verifications being implemented against various hot lists. Having been built with a fairly sophisticated level of multilingual support this application supported the extended character set of national languages of all the European countries complying with SEPA. Therefore, it was able to handle German umlauts and other accent symbols in various European languages. For example, it could treat the German name "Müller" differently from "Muller", which is derived simplistically and incorrectly by ignoring the umlaut symbol.
Now, since the existing legacy payment product processor did not support an extended character set, there was a strong potential for mismatch between the various systems included in the system landscape whenever a term contained umlauts or other special characters (`, ´, ˚, ˜, etc.) commonly found in non-English European languages.
No comments:
Post a Comment