New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bank details #149
Comments
HMRC's 'Register for VAT' prototype. Step 1: Ask for type of accountStep 2: Ask for Bank details (if bank account chosen in step 1)Notes:
Step 2: Ask for Building Society details (if building society chosen in step 1) |
For the Child Funeral Fund service we did this... First we ask a branching question: If UK bank account: If UK building society account: If non-UK bank account: If cheque: Within this service, the user has already entered their name and address, so there are no additional questions asked at this point in order to get paid. Note: we also have an option for “None of the above” as the service will pay in cash meaning there are no dead ends. |
I support the statements by @davehaigh where he says "allow spaces, dashes" in sort code and account number. The guidance on postcodes (
|
Design System working group review session 26/9The GOV.UK Design System working group met on Thursday 26 September to review an Ask users for bank details pattern contributed by MOJ. Here is a summary of the session and outcomes. SummaryThe working group agreed that the bank details contribution can be published in the GOV.UK Design System. The working group also made the following recommendations. Guidance
Examples
Design
Research
Next stepsThe GOV.UK Design System team will work with the contributors to address as many of these recommendations as possible before publishing the pattern. |
I'm glad to see the MOJ example has the sort code before the account number. This matches the sequence used in the IBAN and also matches the ‘general to specific’ sequence. |
This is a great pattern. I'd like to make a small suggestion. Would it be sensible to do a Sort Code Lookup? Once the user has entered their sortcode, display something like "We think this is an HSBC account. If not, please check the details entered". I see this sort of pattern on Credit Card details pages. After typing in the first few digits, the page changes to reflect that it's a MasterCard, Amex, Visa etc. There are APIs for doing this - http://www.fasterpayments.org.uk/sort-code-checker https://www.iban.com/sortware-api https://www.bankaccountchecker.com/documentation/uk/sortcode/json - but I'm not sure if it's within the scope of this pattern. |
The service I work on (New Style Employment and Support Allowance - DWP) recently had an accessibility audit that raised the same issue as hmrc/accessibility#23. The scenario was someone using Dragon and when they naturally pause while saying their account number, it automatically puts a space in-between the numbers. This then causes an error. We have discussed removing spaces before the validation, so we can still check that it's between 6 and 8 numbers. We've spent quite a lot of time talking about if this is the right thing to do, and would have helped if this kind of thing was written down in the pattern. |
@ladine-cook We remove all unwanted characters prior to validation. It's an extra step in the software but simple enough. We're considering this as almost a default style to apply to each field (reference numbers, names, addresses). It eliminates an entire class of error. In these cases, we no longer need an error for unwanted characters because can never happen. This is written down in the pattern for postcodes: The concept is not specific to postcodes. It applies to account numbers as you suggest, and elsewhere. |
We've noticed that autocomplete is enabled on all fields in this pattern. We propose that it should be disabled, as having it enabled presents a security risk on shared/public devices, making it possible for a previously entered account details to be harvested. There aren't any similar comments on this thread. Is this a new consideration for this pattern? |
@lyndsp can you explain what you mean by 'harvested'? From my understanding, the attribute has no bearing on whether the browser stores the details or not. It only affects whether it will offer to fill in existing details. If you mean someone harvesting details from the browser (public computer?), either way the bank details would be there - (providing my understanding of this attribute is correct). |
@edwardhorsford are you thinking of the username/password field which browser just ignore if you use |
@matthewford I don't think so. My understanding is the attributes have no bearing on whether a browser saves them or not. So they should not have a bearing on those details being 'harvested'. |
@edwardhorsford Just tested this in chrome with the example in the Mozilla docs, if you do not include autocomplete off, your back button will prefill the details in the text field, so the details are stored in the session. With autocomplete set to off, nothing is prefilled. |
@matthewford I think storing in session is fine, isn't it? It'll last as long as the session timeout. These details will regardless be shown on a check your answers / confirmation page, so anyone with access to the session already has the full set of details. |
It depends on your risk assessment I guess, back when people worked in offices, someone could access your machine within a session timeout duration, if you left it unattended. |
In regards to the This is also noted in the link pasted above (https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#Disabling_autocompletion)
This could enable people to go to an internet cafe and go to the bank details form on a gov-uk website and then see what auto-complete information is available, allowing them to harvest bank account details (It's a long shot, but entirely possible). |
I'm working with @lyndsp on this, and I can share some insights. There's not really any specific attack vector that we are concerned about regarding data being stored client side, as @edwardhorsford mentioned the browser can sort of do whatever it wants with that information, there's a level of trust involved. As a government organisation however, we have a particular responsibility to make best efforts to limit confusion or concern among our users, as well as preventing them from making security mistakes where possible. I see two benefits to be gained:
Based on the above, I believe turning autocomplete=off for these fields should be the default for this pattern. |
Just to note there's a potentially conflicting accessibility consideration here - that autocomplete helps people who find it hard to type or remember things: |
Questions about this pattern.Question 1What is the consensus on 'playing back' the submission of these bank details in a check your answers or some form of 'confirm these bank details' page? Thinking about security primarily here. Should the confirmation play-back obscure all but the last 4 digits of the account number perhaps? Question 2
I've just remembered summary list |
With this pattern, how might you indicate to the user that there is a mismatch between an entered sort-code and account number (for example the account number doesn't belong to the same bank as the sort-code)? Options I can see are:
None of these seems ideal, but the first one seems the least impactful. |
I'm working on a service in DWP that focuses on how users input bank details, alongside how we present validation of the bank details, tied in with Experian. We've tried these suggestions and found that option 3 was the best of an admittedly bad bunch. Would be interested to hear any alternative suggestions. |
It all depends on what you want to do with the sort code/account number combination. If you have access to EISCD you can see if a Sort code is valid or not and check BACS/CHAPS status. If all you care about is the ability to use BACS/CHAPS you can make the assumption that if the sort code is not on EISCD it is invalid. At this point you can guide the user towards changing their sort code by placing an error message associated with the sort code. Once you know you have a sort code that is on EISCD (and therefore is valid), you can then perform a modcheck to ensure that the sort code/account number combination is valid. If it is not you can place an error message associated with the account number. This is of course as ever not 100% bullet proof. It is possible somebody will fat finger their sort code and manage to put in another valid sort code (it's unlikely, but it is possible). It is also possible that they have multiple accounts and have entered a sort code for a different account they own. At this point an account number error message could be confusing for them, you could try and mitigate this by adding an additional error message if they attempt to submit the same account number multiple times asking them to check that they have entered the correct sort code that is associated with this account number. You could of course modify your error message to say the account number is incorrect or not associated with this sort code, then you don't need the additional logic of multiple attempts to submit the same incorrect error message. I think that this solution would most closely map to option 1. |
I'm working on a service where I'm running into very similar issue as @adamliptrot-oc has highlighted. We validate account number/sort code if there is a roll number present. We have a static list of sort code / account number for building societies that use roll numbers. But the issue here is this validation is triggered only when roll number is present. I'm just wondering how others who are having to use building society roll numbers have built their validation using this form. Another important thing is we are building an internal agent facing service rather than citizen facing one, so are there any concessions that could be made to collect the building society details that would make the journey better? We are planning to highlight all the three fields at the moment. Although it does not indicate which one of those options is incorrect, it could be any of those 3 combinations as our content says so. It feels like at least then agent can try typing in the details again for highlighted "incorrect" fields. |
#214 'Asking for at least one thing' might be relevant |
Error messages for bank details include "Enter a valid sort code like 309430" etc, but the standards for error messages says don't use "‘valid’ and ‘invalid’ because they do not add anything to the message"? |
I'm working on a service which is moving some bespoke pages to collect bank details to this pattern. In this pattern account numbers are expected to be '6 to 8 digits' long, but the existing page says account numbers are '8 digits' long. Just wanted to confirm if 6 digit account numbers are common, if so who usually has 6 digit account numbers please. This will clarify whether we need to change the validation rules accordingly. Thanks |
6 digit account numbers are normally prefixed with 0's to bring them up to 8 digits. From personal experience an old LLoyds account I had used to have, had 7 digits, so I know they don't always have 8 digit account numbers. I assume they aren't the only ones. |
I am working on the new digital service for Child benefit which can be found here: https://chb-prototype.herokuapp.com/ The service team (representing the business' views) would like the Account holder's name field to be two fields: First Name and Last name (exactly as they appear on your bank account) The reasons for this are two fold:
I have been asked to research why the pattern is how it is with one name field and so my questions are:
|
An alternative to these services is Mintly https://www.mintly.uk. We offer a sort code and account number validation API, which gives users confidence that their data has been entered correctly. Would be happy to set up a demo to showcase the capabilities. We use the latest EISCD data, and a simple subscription model. |
We have removed the 'Experimental' tag from components, patterns, and guidance in the Design System. 😌 The tag was being used on the Bank details pattern to raise awareness that more research is needed to validate it. However, we recently published new guidance on how to share findings from users which we hope will make it easier to collect and format more information about how the Design System is being used across services. If your team has used this component please let us know. 💪 |
Does anyone know why there isn’t a specific error message for a too long or too short sort code in the design pattern? There is for account number and building society roll number. We’re looking to add one for our service but wanted to check if there was a strong reason not too? |
Is there a reason why the pattern uses |
Thanks @adamliptrot-oc – I've asked the team and I don't think we considered The only immediate reservation we have is that |
Many browsers now offer a feature where it will autofill payment card details, filling in all the details for a card at once. When you have multiple cards saved, a typical user interface is that when you begin filling in one input related to card, it lists all your cards and when you select one, it will fill in all the other inputs using the details from that specific card. I’m not aware of any browsers that treat bank account details in the same way and I’d be concerned using On the other hand, So I’d be hesitant to change to |
I took a look at the original WHATWG email discussion and it seems that "cc-" is purely a legacy thing:
Yes, a possibility though I'd expect browsers also do some heuristics to verify that the other fields are also present? Some testing to be done perhaps, but from a brief test a lone There is potentially no difference in actual output between the two. Browsers might default a We also know there are no autocomplete values appropriate for bank details (I think IBAN was added at some point, but not "regular" country-specific ones like account numbers, sort-codes and roll-numbers) so we are unable to offer to fill the rest of the information like we might try (or try not to) for a payment card. So does it then come down to any other potential use case for autocomplete attributes? The WCAG guidelines offer that there is potential for assistive tech to utilise these attributes to better communicate the purpose of the input to the user (perhaps through placement of appropriate icons alongside). In this case a payment instrument name might be better suited than a simple name. However I can't say I've seen any of this in practice. Edited to add sidenote: Some interesting bits of information from that mailing list discussion from 2012, including the original reasoning for the
|
What
Help users provide bank details so that you can make payments to them or accept payments from them.
Why
Services using this pattern:
Anything else
The text was updated successfully, but these errors were encountered: