0

We're currently working on a new product that extends a 3rd party product. The product needs to store the bank account number of employees. The product is aimed at Belgian enterprises, and since February 2014, all European bank transactions need to use the new SEPA-style bank account number (34 symbols with a country code).

In our current internally used version (which has never been used outside our own system and will be replaced by the product in development), since this was in use in 2013, we have support for the classic pre-SEPA method used in Belgium (###-#######-##). However, this method is no longer supposed to be used, and we managed that in our internal version by immediately validating and converting the number on the client side.

However, every number in use in Belgium currently is using the SEPA style. All debit cards with the pre-SEPA style should have been replaced by now. We are not allowed to use the pre-SEPA style anymore, not even for purely national use. Given that this is an international guideline which has already been through the transition period, should we still support this legacy format, considering it has been replaced (only?) 5 months ago by now?

A similar concern is about something specific to Belgium: Belgium is currently phasing out the SIS-card, a card which was used for social security, and merging that functionality into the electronic ID card. The nation is currently in a transition period that is expected to end by 2015, with most hospitals and pharmacies already being transitioned and most cards already expired or expired by the end of this year. However, the e-ID connection is not supported 100% everywhere yet (which also is quite troubling for those whose card expired in 2013, like me, because they might run into trouble there). Should this number still have support while it's in the transition period?

|improve this question
2

What about providing a seperate conversion tool to support anyone else that is stuck with old data?

You could detect if someone is trying to enter it using the old format, and then provide a helpful link to the conversion tool (web based).

|improve this answer
  • We'd rather not do this, because we don't have a really userfriendly way of notifying the user. And since we already have the logic to validate and convert the old format, and since both products use the same framework, we could just keep the current method of validation since it's 99% compatible and requires minimal effort. I'm mainly just wondering, since it's additional complexity in the code that needs maintaining, if not providing support for it is acceptable from a UX perspective. – Nzall Jul 15 '14 at 14:11
  • @NateKerkhofs Ah, my solution is designed to discourage use of old format, but still provide a solution for users who are really stuck / unable to convert their old data. If you don't care about discouraging users then I would say to just support both. – Franchesca Jul 15 '14 at 14:30
  • The old data is obsolete in the case of the bank account, and conversion is rather trivial (3 lines of code). The main reason I'm wondering about it is because we're not sure if anyone still uses the old format (they really shouldn't and are in serious trouble if they haven't transitioned yet), and whether it's acceptable to stop supporting something when it's been phased out on a national and international scale for over 5 months now. To clarify: it's the format that's legacy, we don't have any legacy data already in the system that we need to support. – Nzall Jul 15 '14 at 14:34
  • @NateKerkhofs It really depends on who your users are. If you do stop support, are you going to have users who are "stuck" with loads of data in the old format? If so, do you care? If your business model depends on not giving these kinds of people a bad "experience", then keep supporting it. Otherwise just get rid of support. – Franchesca Jul 15 '14 at 15:02
  • If we choose to support the old format, we're not going to store it in the old format, but in the nex format that everyone needs to use. The conversion is trivial (basically some modular arithmetic and a few string concatenations), it's mainly whether anyone even still uses the old format. And it's a completely new product, so there's not really a risk of users having old data in their system. – Nzall Jul 15 '14 at 16:42
0

I would suggest rolling out with supporting both styles until all Belgian banks have been converted to the new ones. Unless the bank are being forced to switch, they might take their sweet time to do so, which will block some users from using your product.

Do you have available user demographics of how many people are still using the old style number over the new one? This might make it easy to make this decision.

|improve this answer
  • Banks are already forced to use the new system in all their communication since february of this year (as I mentioned above), along with every company that needs to pay or receive money. Everyone uses the new system, the question is if we should still provide support for the old system. We don't have to worry about individual users, because the product is a corporate product, and corporate requirements require the new version. – Nzall Jul 15 '14 at 14:15
  • From your answer it would seem that your target audience does not need to use the old system. It doesn't seem like there would be any benefit from supporting the old system. Providing information for users who are still using the old system might be as far as you go for support. Seeing as you're dealing with a corporate product, it is ideal to delegate such a requirement to your customers and make sure they comply with your product. – Daniel Zahra Jul 15 '14 at 14:29
  • We're 99% sure that we won't need the old bank account system. We're less sure about the SIS-card, because that's still in the transition period and not all hospitals accept the e-ID yet. – Nzall Jul 15 '14 at 14:31
0

A general rule of thumb for any data: If you can't use it, don't store it.

Since you already mentioned you are not allowed to use it anymore, and all current data has been transformed, don't ask for it.

Who would benefit from you allowing a user to enter a number you can't use? The first time the customer wants to issue a transaction based on the number, you'll have to show an error stating "Your account number is invalid".

I think the latter would be a lot more frustrating if I was just allowed to enter it 5mins earlier.

One exception: If you are able to convert it with 100% accuracy, it will be an added benefit for the user experience. Let them enter one or the other, and always store it in the new form and notify the user of the transformation.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.