Financial Data Exchange (AKA: FDX)

[John Pollard]

I suspect that Quicken users who download data (with the exception of those who use the Web Connect connection method to download) are going to be increasingly encountering FDX as time passes.

Schwab users, for example, are already dealing with FDX, since FDX is the new standard for pulling data from financial institutions for downloading to financial software. Quicken's mechanism for handling FDX is Express Web Connect+ (EWC+).

The two primary benefits of FDX are said to be: enhanced security (better than not only Express Web Connect, but better than Direct Connect * ); and the elimination of any need for "screen scraping" (which at its best is problematic, and is constantly under the threat of being broken by having the financial institution change the format of their web site).

FDX will employ an expiring "token" (authorized by the customer/user) to access the financial institution data - rather than the customer/user User-ID/Password.

FDX will use a non-proprietary API to select the accounts, and the items of data from those accounts, to be downloaded.

As I understand it, Quicken itself will not be employing FDX directly as Quicken will not be accessing the financial institution's FDX data directly; Quicken's aggregator, Intuit, will be the one actually dealing directly with FDX. But the data Quicken receives will, apparently, no longer be in OFX format.

The Quicken OFX Log has not contained data from Express Web Connect downloads for some time now: that will remain true for Express Web Connect+ as well.

Given that FDX appears to have better security than even Direct Connect; and, it appears likely, will be cheaper than Direct Connect: my guess is that more and more financial institutions will be switching to FDX - and that will mean more and more Quicken users will be employing EWC+ to download.

[ (*) After composing the above, I have been told by a knowledgeable person that the same security approach being employed by FDX, can also be used by OFX. The newest OFX specs specifically allow for the same security approach as that used by FDX. Meaning that Intuit/Quicken can choose to make Direct Connect as secure as FDX ... though possibly not as inexpensive as FDX.]

Here are current FDX members: https://financialdataexchange.org/FDX/The%20Consortium/FDX/The-Consortium/Members.aspx?hkey=362ecd23-b752-48aa-b104-a99e916276c8

Here are some FDX FAQ's: https://financialdataexchange.org/FDX/About/FAQs.aspx

Here is the FDX Home page: https://financialdataexchange.org/

[Andrew]

John, as usual, thank you for this post and explanation. I feel "lucky"
I had the experience of dealing with EWC+ with my overall fine Schwab
migration experience a few weeks back, and as someone who enjoys
understanding electronic banking, this post and references are quite
interesting to me.

--
-------------------------------------------------------------
Regards -

- Andrew

[Sherlock]

I share your suspicisions and concerns.

My understanding is the sole security benefit of the FDX API is the MFA
authentication of the token (aka certificate).

I do hope Quicken Inc. does decide to join the consortium and is able
provide a direct connect-like access using the FDX API. I guess they'd
call it: Direct Connect+.

Note: The weaknesses inherent in the Express Web Connect connection
method persist in EWC+. Most notably, stale data and the lack of
payment services.

As acceptance of the FDX API spreads, I expect we'll be seeing better
aggregation services at the member portals.

[John Pollard]

On Saturday, December 11, 2021 at 3:56:11 PM UTC-6, Sherlock wrote:

> I share your suspicisions and concerns.
>
> My understanding is the sole security benefit of the FDX API is the MFA authentication of the token (aka certificate).

This is not my area of expertise, but I understood that the improved security also included not having the logon credentials available to Quicken, et. al.. And to having the token "expire" fairly "quickly" - reducing the likelihood of its being misused by others.

That thought led me to believe that FDX/EWC+ might not lend itself to being part of a legitimate One Step Update (as I already do not think EWC with MFA is a legitimate part of a One Step Update): I'm thinking that expiring tokens will require re-authorizations, which I picture as users being required to repeatedly supply logon credentials to successfully re-authorize. Sadly, I don't think the financial institutions would care much about Quicken users experiencing a degraded OSU.

I'd be happy to be proven wrong about the repeated re-authorizations.

> I do hope Quicken Inc. does decide to join the consortium and is able
> provide a direct connect-like access using the FDX API.

As do I. Quicken (and Intuit) are already members of FDX; but I'm not sure what that means in terms of Quicken's willingness/ability to bring Direct Connect up FDX standards.

> I guess they'd call it: Direct Connect+.

"Direct Connect+"; I like that. :)

> Note: The weaknesses inherent in the Express Web Connect connection method persist in EWC+.
> Most notably, stale data and the lack of payment services.

I agree and am not happy about it - especially the loss of online billpay support when Direct Connect financial institutions elect to switch to EWC+. Hopefully Direct Connect+ will be the way around that.

> As acceptance of the FDX API spreads, I expect we'll be seeing better aggregation services at the member portals.

Though I'm generally a skeptic, I have a hidden optimistic side. My hidden optimism wishes (and even assumes) that you're right.

I believe that the changes required to support FDX are fairly significant, and that the Quicken customers of the financial institutions that are early adopters of FDX have borne the brunt of that difficult change. I'm not sure Quicken can withstand repeated results like those experienced by Schwab users (for example).

[I have another concern about all this, which is the possible impact of a previous Quicken change: the creation and use of Cloud files. I don't think the ramifications of Quicken's use of Cloud files is very well understood by more than a handful of Quicken users: and my suspicion is that some users have already run afoul of problems with Cloud files. I think that some users having problems switching from EWC to EWC+ may not be aware that (I believe) having multiple QDF/Cloud files could be having an impact. One possible example I believe is those users who have a "test file" where they attempt to work out Quicken problems - including those who prefer to test new Quicken releases in a test Quicken file. It seems to me that users who have multiple QDF files may be creating problems for EWC/EWC+ downloads. I've found it extremely difficult to pin down the actual impact of multiple QDF files on EWC (and now EWC+), but I suspect there may be problems there. And I'm completely ignoring the "effective" loss of Quicken "Copy" to remove logically deleted Quicken data, etc. - having to re-activate all activated accounts is too high a price to pay for Quicken's choice to use Cloud files as they do.]

[Sherlock]

On 2021-12-12 03:19:01 +0000, John Pollard said:

> On Saturday, December 11, 2021 at 3:56:11 PM UTC-6, Sherlock wrote:
>
>> I share your suspicisions and concerns.>> My understanding is the sole
>> security benefit of the FDX API is the MFA authentication of the token
>> (aka certificate).
> This is not my area of expertise, but I understood that the improved
> security also included not having the logon credentials available to
> Quicken, et. al.. And to having the token "expire" fairly "quickly" -
> reducing the likelihood of its being misused by others.
>
>
> That thought led me to believe that FDX/EWC+ might not lend itself to
> being part of a legitimate One Step Update (as I already do not think
> EWC with MFA is a legitimate part of a One Step Update): I'm thinking
> that expiring tokens will require re-authorizations, which I picture as
> users being required to repeatedly supply logon credentials to
> successfully re-authorize. Sadly, I don't think the financial
> institutions would care much about Quicken users experiencing a
> degraded OSU.
>
> I'd be happy to be proven wrong about the repeated re-authorizations.

Correct. The availability of the MFA authentication of the token
replaces the requirement to provide sign-in credentials while the token
remains valid.

I suppose "expire" fairly "quickly" is subjective. I suspect
expiration will be on the order of months.

>
>> I do hope Quicken Inc. does decide to join the consortium and is able>
>> provide a direct connect-like access using the FDX API.
> As do I. Quicken (and Intuit) are already members of FDX; but I'm not
> sure what that means in terms of Quicken's willingness/ability to bring
> Direct Connect up FDX standards.

I hadn't realized Quicken Inc. had joined. That is good to know.

>
>> I guess they'd call it: Direct Connect+.
> "Direct Connect+"; I like that. :)
>
>> Note: The weaknesses inherent in the Express Web Connect connection
>> method persist in EWC+.> Most notably, stale data and the lack of
>> payment services.
> I agree and am not happy about it - especially the loss of online
> billpay support when Direct Connect financial institutions elect to
> switch to EWC+. Hopefully Direct Connect+ will be the way around that.
>
>> As acceptance of the FDX API spreads, I expect we'll be seeing better
>> aggregation services at the member portals.
>
> Though I'm generally a skeptic, I have a hidden optimistic side. My
> hidden optimism wishes (and even assumes) that you're right.
>
> I believe that the changes required to support FDX are fairly
> significant, and that the Quicken customers of the financial
> institutions that are early adopters of FDX have borne the brunt of
> that difficult change. I'm not sure Quicken can withstand repeated
> results like those experienced by Schwab users (for example).

I agree. In my opinion, Schwab mismanaged the transition but many
Quicken users won't see it that way. I'm very thankful we closed our
Schwab accounts years ago.

>
> [I have another concern about all this, which is the possible impact of
> a previous Quicken change: the creation and use of Cloud files. I don't
> think the ramifications of Quicken's use of Cloud files is very well
> understood by more than a handful of Quicken users: and my suspicion is
> that some users have already run afoul of problems with Cloud files. I
> think that some users having problems switching from EWC to EWC+ may
> not be aware that (I believe) having multiple QDF/Cloud files could be
> having an impact. One possible example I believe is those users who
> have a "test file" where they attempt to work out Quicken problems -
> including those who prefer to test new Quicken releases in a test
> Quicken file. It seems to me that users who have multiple QDF files may
> be creating problems for EWC/EWC+ downloads. I've found it extremely
> difficult to pin down the actual impact of multiple QDF files on EWC
> (and now EWC+), but I suspect there may be problems there. And I'm
> completely ignoring the "effective" loss of Quicken "Copy" to remove
> logically deleted Quicken data, etc. - having to re-activate all
> activated accounts is too high a price to pay for Quicken's choice to
> use Cloud files as they do.]

Again, I agree. I think there are variety of issues that stem from
Quicken's decision to use of a fixed identifier for a Quicken file as
the link to a cloud account.

[John Pollard]

On Sunday, December 12, 2021 at 3:29:58 AM UTC-6, Sherlock wrote:

> I suppose "expire" fairly "quickly" is subjective.
> I suspect expiration will be on the order of months.

I sincerely hope you're correct. My thought was that users were experiencing the requirement to authorize much more frequently than that. While I realized that certainly could have been a problem in the implementation, I also feared it might be a desired "feature".

[The skeptic in me is reluctant to assume that FDX will eliminate the necessity for the current 2FA interruptions to EWC downloads, but I can't imagine why they would still be needed so I can hope.]

I'm also hoping that the reported limitation of one EWC+ authorized Quicken file per financial institution is not going to be a permanent restriction. I like to be able to preview the impact of new releases in a test file: bad enough to fight the Cloud Sync issue for multiple Quicken files; being also prevented from doing that new release preview for EWC+ financial institutions would be a really bad outcome from my point of view.

> I'm very thankful we closed our Schwab accounts years ago.

I wound up at Schwab because USAA gave up on handling investments and sold their investment accounts to Schwab. Up until just recently, I rather liked Schwab.

[Sherlock]

On 2021-12-12 15:34:36 +0000, John Pollard said:

> On Sunday, December 12, 2021 at 3:29:58 AM UTC-6, Sherlock wrote:
>
>> I suppose "expire" fairly "quickly" is subjective.> I suspect
>> expiration will be on the order of months.
>
> I sincerely hope you're correct. My thought was that users were
> experiencing the requirement to authorize much more frequently than
> that. While I realized that certainly could have been a problem in the
> implementation, I also feared it might be a desired "feature".

My hope is that it'll actually be on the order of years.

>
> [The skeptic in me is reluctant to assume that FDX will eliminate the
> necessity for the current 2FA interruptions to EWC downloads, but I
> can't imagine why they would still be needed so I can hope.]
>
> I'm also hoping that the reported limitation of one EWC+ authorized
> Quicken file per financial institution is not going to be a permanent
> restriction. I like to be able to preview the impact of new releases in
> a test file: bad enough to fight the Cloud Sync issue for multiple
> Quicken files; being also prevented from doing that new release preview
> for EWC+ financial institutions would be a really bad outcome from my
> point of view.

They do appear to have eased this constraint recently. Instead of the
file identifier, they now appear to be using the Quicken ID:
https://community.quicken.com/discussion/7900567/updated-12-8-21-changes-to-charles-schwab-accounts

[John Pollard]

On Sunday, December 12, 2021 at 5:29:57 PM UTC-6, Sherlock wrote:
> On 2021-12-12 15:34:36 +0000, John Pollard said:

> > I'm also hoping that the reported limitation of one EWC+ authorized
> > Quicken file per financial institution is not going to be a permanent
> > restriction. I like to be able to preview the impact of new releases in
> > a test file: bad enough to fight the Cloud Sync issue for multiple
> > Quicken files; being also prevented from doing that new release preview
> > for EWC+ financial institutions would be a really bad outcome from my
> > point of view.

> They do appear to have eased this constraint recently. Instead of the
> file identifier, they now appear to be using the Quicken ID:
> https://community.quicken.com/discussion/7900567/updated-12-8-21-changes-to-charles-schwab-accounts

Thank you! That is very welcome news for me.