govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Bank details
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
- DWP has a version called Banking details: DWP design patterns
- HMRC Pay your tax bill service
- GOV.UK Pay
HMRC's 'Register for VAT' prototype.
Step 1: Ask for type of account
Step 2: Ask for Bank details (if bank account chosen in step 1)
Notes:
- pre populate bank name if name of company/individual is known
- sort code: one field, half width (to indicate length), lenient with format (allow spaces, dashes), use hint text to prevent users guessing to which format is/isn't allowed. Splitting into 3 fields causes accessibility and usability issues: e.g. how do you read out each field to a screen reader ("1st part of sort code", "2nd part of sort code - 3rd and 4th digit", etc)? Also 3 fields don't allow a user to paste a sort code.
- account number: be lenient with format (allow spaces, dashes)
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.
Other examples of this in use in gov:
GOV.UK Pay:
OPG's Claim a power of attorney refund:
HMRC's Tax-free childcare account:
I support the statements by @davehaigh where he says "allow spaces, dashes" in sort code and account number. The guidance on postcodes (https://design-system.service.gov.uk/patterns/addresses/) says to allow
- "additional spaces at the beginning, middle or end and punctuation like hyphens, brackets, dashes and full stops."
I recommend the same applies for account numbers and sort codes. This is because users sometimes enter characters like those: it can be because of cut&paste; it can be because of key bounce; it can be because of a variety of reasons. It's better to accept and discard unnecessary characters than to tell users the whole thing is invalid. Similarly if an account number or sort code is supposed to have non-alphanumeric characters (e.g. spaces, hyphens), it should still validate without them. Thus '112233' should be accepted as a sort code. Furthermore, if validation relies on counting characters, it should be sensitive to these issues. Examples of what can go wrong are: sortcode field won't accept more than six characters; or validation rule is
. This means the user can't cut and paste a sort code with hyphens (sometimes from the same website).
Design System working group review session 26/9
The 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.
Summary
The 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
- Add guidance on asking for bank details safely and securely, for example, not over email.
- In the section on error messages, use “full stop” instead of “period”.
- Ensure the guidance has a final 2i before it’s published.
- Be more emphatic about the fact that this pattern doesn’t contain all of the information required to collect international bank details.
- Be more explicit about the fact that this pattern does not yet cover the direct debit journey, although it is a valid use case for asking users for their bank details.
- Make clearer that the branching question shown is an illustrative example only and will need to be adapted to context depending on what users need and the service can support in terms of payment options.
Examples
- Reconsider sort code example as not confident that the current one will be familiar enough to users as a sort code.
- Change account number example used in error message to one with 00 at the start to show that this is OK.
Design
- Consider whether “Name on the account” field could be clearer, for example, “Name on card”.
- Consider if sort code field width can be reduced to emphasise expected sort code length.
- Consider adding a hint with a sort code example to the sort code field to show that spaces and dashes are OK.
- Consider if hint text could be written with more detail to help users identify the correct numbers.
- Hint text on account number may need to be changed as some account numbers can be up to 10 digits long.
- Consider swapping “Non-UK” in the branching question for “International” or “Foreign” as an HMRC team found “Non-UK” was misinterpreted when testing with French-speaking users.
Research
- Document credit union accounts as a known gap, as users of this pattern may need to support them.
- Make clearer how this pattern has (or has not) been researched.
Next steps
The 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 https://github.com/hmrc/accessibility/issues/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: https://design-system.service.gov.uk/patterns/addresses/ "It is easier for users if you accept and ignore unwanted characters. This is better than rejecting the input and telling a user they’ve not provided a valid postcode. You should allow postcodes that contain upper and lower case letters, no spaces, additional spaces at the beginning, middle or end and punctuation like hyphens, brackets, dashes and full stops."
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 autocomplete=‘off’, as other fields should respect this option in most browsers.
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#Disabling_autocompletion
@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 automcomplete=off suggestion, this isn't a session issue, it's a browser storage issue. If you don't set autocompletion to off the browser will store this data (i.e. the users sort code and account number) in a browser cache, and then suggest it in the future for input elements that share the same name attribute.
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)
It tells the browser not to save data inputted by the user for later autocompletion on similar forms, though heuristics for complying vary by browser.
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:
- Reduce the likelihood of user bank details being stored on a public computer
- Reduce the likelihood of a user complaint when bank details they shared with a Gov department show up in an autocomplete box on another site
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:
https://www.w3.org/WAI/WCAG21/Techniques/html/H98
Questions about this pattern.
Question 1
What 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
~~Assuming we decided to 'playing back' the submission how would mark them up in HTML? Is it a definition list?~~
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)? Assuming checks are done on submission and the two do not collate, we will not know which one the user mis-typed.
Options I can see are:
- Do we assume that last-typed field is the incorrect one and place the error on that?
- Do we need to wrap the two fields in a fieldset and set the error on the fieldset to cover both - this leaves the error a little remote from the second field?
- Do we take the user to another page to explain the issue and replay the entered information with a. link back to the form?
- Do we place an error on both fields saying the entered data does not match the other - which could cause confusion as it suggests two fields are 'incorrect'?
None of these seems ideal, but the first one seems the least impactful.
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)? Assuming checks are done on submission and the two do not collate, we will not know which one the user mis-typed.
Options I can see are:
- Do we assume that last-typed field is the incorrect one and place the error on that?
- Do we need to wrap the two fields in a fieldset and set the error on the fieldset to cover both - this leaves the error a little remote from the second field?
- Do we take the user to another page to explain the issue and replay the entered information with a. link back to the form?
- Do we place an error on both fields saying the entered data does not match the other - which could cause confusion as it suggests two fields are 'incorrect'?
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.
https://github.com/alphagov/govuk-design-system-backlog/issues/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:
- the backend HoD (backend system) has it as two fields
- we are using BARS3 which does both account checking to see if it is a well formed account number and then name checking to see if the name and account numbers match. This can support perfect (full) match exactly as on the account statements (not what is written on the bank card, or including title or middle names or initials), or partial match which needs the surname to be right and can work with an initial. Security have decided (for now) that a full match is the way to go and so two fields supports this better.
I have been asked to research why the pattern is how it is with one name field and so my questions are:
- is there any evidence for name as one field rather that first name/last name in the banking context?
- Is any other service working with BARS3 and are they/you using partial or full match?
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.
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.
