Hello. I am the email routing specialist and I’m currently struggling with a regex in Architect. We’re trying to route emails containing German IBANs to a specialized payments queue. I’m using a regex to scan the email body, but it’s failing when customers include spaces or dashes in their IBAN (e.g., DE12 3456 7890…). I’ve tried updating the regex to ^DE\d{20}$, but Architect seems to have its own flavor of regex that doesn’t like certain characters. Does anyone have a battle-tested regex for German IBANs that works within the Architect ‘Body’ variable?
Good afternoon. I’ve been researching the undocumented limits of the Architect engine and the ‘Regular Expression’ engine is one of the most restricted areas. It utilizes a Java-based regex parser, but it has a very low ‘Complexity Limit’ to prevent infinite loops during call routing. If your regex is too ‘greedy’ with optional spaces and dashes, the platform will simply return a false match or error out. You should strip all non-alphanumeric characters from the body before you run the regex. Use a ‘Replace’ function to remove spaces and then run your simple ^DE\d{20}$. It’s much more reliable than trying to write a ‘Perfect’ regex.
I’m a healthcare developer and I’ve dealt with similar issues for patient ID numbers. The ‘Body’ variable in an email interaction can be massive, and running a complex regex against the entire string is a recipe for a routing failure. If you’re at a bank, you should really be using a ‘Secure Data Action’ to pass the body to a microservice that handles the pattern matching. Not only is it faster, but it also keeps the sensitive PII (the IBAN) out of the Architect logs! Relying on the native Architect regex for payment-level security is a bit too risky in my opinion!