Hi
I use the Chrome Extension to feed bank entries for one client who has a Nat West Account.
Am I right in thinking that if I have another separate client with their own Nat West Accounts that I will have to change all the settings each time I want to feed bank entries with their account ?
So, If I had 10 separate clients I would need 10 sets of settings I would have to enter each time I’m working for any individual client ? Or am I wrong ?
Many thanks
You are correct yes, I’m afraid the Chrome plugin does not support multiple accounts.
With the recent introduction of our Yodlee integration your clients can now setup their own feeds with Natwest so the transactions automatically import into the account without needing to do this manually.
Hi
I thought so, thanks for that.
The trouble with some of the Nat West Business accounts are that they are earmarked to be transferred off to Williams & Glynn Bank in due course and won’t work with Yodlee I don’t think.
Unfortunately yes, those divested accounts won’t initially work with Yodlee. I believe however Yodlee do eventually intend to support Williams & Glynn, but I’m not aware of the timeframe.
Another potential workaround (I’ve not tested this myself)…
Chrome lets you create additional users. For each user I believe you can setup the Chrome Feed with different credentials that get stored for that specific Chrome user. All you need to do then is switch between them.
I’ll fully test the work around tomorrow but it looks like it will work.
Genius, many thanks
Whilst this I’m sure is a great ‘quick fix’ suggested in absolute good faith, I have to say that I think it is potentially dangerous for QF to put forward this without a huge caveat;
So for the benefit of others that may read this and consider taking this approach I would like to put forward my own huge caveat!
To provide some context I previously had the great displeasure of working on several large IT contracts (inc. UK Gov) for best part of 15yrs.
My wife’s small business was also a customer of {cough} ‘SpeakSpeak’ 
and we benefited immensely (not!) from their release of our all our account and subsequently bank details, to the public…
As such I feel I’ve a pretty good background in understanding the challenge of IT-vs-Big Data-vs-Security. Sadly on more occasions than I would care to (or legally be able to) say, temporary solutions or workarounds for system issues - provided in good faith (sometimes even contracted for by a customer) further down the line turn into huge holes, messy challenges or (worst case) exposures of customer data.
Please also note I am in no way criticising or singling out the OP (@Echohead) for any wrong doing. I’m absolutely certain that they are simply trying to service their clients in the most expedient & efficient way as possible and that is perfectly reasonable, understandable and commendable 
What I want to bring out is that the underlying approach to this is risky…maybe borderline dangerous and I personally think that it is unwise for QF too, in effect, openly promote this.
What’s the risk?
The plugin requires ‘you’ (the individual account holder) to pre-populate your banking information and store this within Chrome.
In doing so you acknowledge that ‘you’ are directly providing this information for ease of reporting and accept that ‘you’ will be required to ensure that the details remain safe i.e (secure the machine, password account, virus scans etc. etc.)
If this local security is compromised (you loose the PC for example) then the consequences are on your own head should the data be misused etc.
In the instances where the individual chooses to share this information with another 3rd party, be it a bookkeeper, their accountant, or service provider such as Yodlee etc. then the duty of care and responsibility for security of that information, (and the fallout should it go awry) should be outlined within the personal agreement between those two parties.
Now, legalities aside of sharing said login information; (I’m still on the fence regarding Yodlee -> keen to embrace the updated accuracy and efficiency but still waiting for my bank to actually answer my “what happens when it goes wrong - have I personally breached my bank ToS?” question)
What this workaround essentially proposes is that:
This poses the following (rhetorical) questions which the individual/organisation using this approach would need to satisfy and safeguard against:
Is it appropriate for the individual to be storing this information, are we assuming that everyone that uses this approach is a legitimate service provider?
If you store and process sensitive information on behalf of the general public within the UK, you need to be compliant with the Data Protection Act. If you are processing financial information do you then not need to register as an individual or orgainsation with the ICO https://ico.org.uk/.
How is the data itself stored within the plugin file? In the clear? Unencrypted?
What effect does having multiple browser windows running with multiple versions of the plugin have on cookies - is each instance saved as a new cookie and therefore each account entry saved in the browser’s history?
How does the features of profile sync across devices effect the plugin - if it’s synced automatically has every Android/Apple/Windows device which that Google account exists on now hold a copy of all the 3rd party account information?
What about standard automated Google backups/drive, will 3rd party sensitive data potentialy end up being stored on a personal account drive?
Finally how would the individual physically secure this data?
From a security perspective one of the better ways of protecting data is to have as wide an attack surface as possible and achieve this by mitigating as far as you can, all the single points of failure. Yet in this instance we’re actually encouraging the information to be stored in a single space, on a single profile (and likely) on a single workstation [[discounting Chrome profile/google drive auto sync, backups etc.]]
If that device/any device it’s connected to/that account/heck even that individual is compromised at all, then you will have exposed every account, of every 3rd party in one single instance.
The OP gave an example of 10’s of accounts, but theoretically you could tweak the Chrome settings and have perhaps 100’s if not more?
I’m not saying that this is realistic or even a likely use scenario - what I wanted to draw attention too is that by advertising this as a workaround QF sets (for me at least) a dangerous precedent and potentially exposes issues further down the line if (or when) something goes wrong and customers data is released.
I am not trying to be overly dramatic, and perhaps my experiences have made me somewhat jaded on the issue, but I think that whenever a workaround is used, in spite of good intentions/cost savings etc. that the impact of how that affects the integrity and/or security of the underlying data should be fully explored, documented and understood by both parties.
For me the use of these sort of tools & workarounds, deciding how the data is stored on behalf of 3rd parties and the manner in which it is to be processed, should all feature prominently within the discussion & agreement with the 3rd party/agent.
Whilst it’s absolutely right to expect QF to set best practice in using its own products and request that providers pass this on to their end users, as I’m sure Sage, Xero and others do, I would be incredibly hesitant of putting forward workarounds such as this that could expose QF to a world of pain in the future.
Tldr; I love using QuickFile, I enjoy the community and the fantastic support that is provided and I am a paying subscriber through choice.
I want to ensure that the folks behind QF can keep the lights on, the heating going and be able to further develop the service into the future.
What I would absolutely hate to see is that this is all for nought and swallowed up in legal fallout when company X discloses personal data for mr & mrs Y, citing workarounds such as this as ‘QF approved system use’.
John.
Thank you for your input John,
Firstly I should say that the Chrome extension was designed for a single end-user and it was never designed to hold credentials for multiple users. It also purposely does not store all credentials and can indeed be set to store no authorisation credentials at all.
The workaround suggested was always discussed in the context of a single user having multiple accounts (in their name), in this respect the security aspect is no different from a single user with a single account.
Browser level privacy is dependent on the integrity of the machine you are using and assumes that appropriate measures have been taken to secure that machine (e.g. OS level password and Antivirus software). We provide these tools as a convenience to our users and as an option for those that do not wish to disclose login credentials to a 3rd party.
It is our objective to deliver the widest range of bank feed options we can, some of those options will require a greater degree of responsibility for the end-user in terms of security. As more direct API feeds become available (and we are hoping to see some headway here in 2018), this will be a key focus for us.