Chase moves to Open Banking API

Dawid Wrobel me at dawidwrobel.com
Sat Oct 8 23:01:27 BST 2022


On Sat, Oct 8, 2022 at 11:37 PM Jack via KMyMoney-devel <
kmymoney-devel at kde.org> wrote:

> That's exactly how these "Open" APIs work. That's not the problem,
> > actually, we could totally use those APIs instead of Direct Connect.
> > The problem is the added requirement of being a pre-authorized entity
> > via on-purpose-issued certificates, as opposed to a regular TLS
> > encryption.
>
> That's not my understanding.  I've seen mention of a one time
> authorization for the bank to give your data to Intuit (and I'm still
> not sure where Yodlee fits in.)


OK, I see where the confusion is. What I was describing is how the process
looks in authorizing the business behind the application/service (think:
FinTech) with the Bank itself.

>From a user's perspective, you need to authorize that very
application/service to use your *actual* account. For that, the
application/service will contact the bank, present you with a pop-up window
that the *bank* provides, which will ask you to perform the 2 Factor
Authentication — be it with a code sent to your phone, or, increasingly,
directly in your bank's Andoid/iOS app. Once this is done, they would
present you with information over what kind of permissions would that
app/service have and let you you decide which of your account(s) you would
want them have that access to.

It sounds to me that when you request data in Quicken, it talks to Intuit.


I can't tell. Technically speaking, Quicken as a standalone app could be
talking directly to the banks using their APIs. In which case you would be
the only person in possession of your financial data, outside of the bank.
Whether they do it like this, or they pass that information through
Intuit's intermediary servers, that can probably be inferred from Quicken's
T&Cs. Chances are that Intuit being Intuit, same company behind Mint, which
makes money off of user's data, would likely find it too hard to pass on
that revenue avenue.


That purpose-issued certificate you mention is used to secure the
> connection between Intuit and the
> bank, but it means your data does flow through Intuit.


Certificates can be used directly by the application itself, there doesn't
have to be some inherent intermediary.


> (I don't really trust Intuit much more than I trust Yodlee.)


Yodlee is an aggregator. They provide services to other FinTech companies
if they don't want to be dealing with each bank individually.
Quicken/Intuit used to use them before Open Banking API was a thing, but
nowadays, AFIK, they deal with banks directly. Other software, like
Banktivity, resorts to said aggregators, because they don't have enough
resources to maintain legal and technical aspects of maintaining direct
connection with all the many banks out there.


Even if KDE/KMM could become such a pre-authorized entity, I don't think we
> want to become
> that type of middle-man.


As explained above, there's no middle-man in such a scenario, just like
there already isn't for the clientele of German/Swiss/Austrian FinTS banks
that KMyMoney is authorized for already — althgouth that doesn't actually
involve certificates.


> I'm sure I"m missing something, and I'd love to see a more detailed
> description of how it all actually works.
>

Hopefully I was able to help.

-- 
Best Regards,
Dawid Wrobel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20221009/38569478/attachment-0001.htm>


More information about the KMyMoney-devel mailing list