KashFlow implies insecurity among SaaS finance solutions using Yodlee

by admin on February 29, 2012

in Cloud Computing/SaaS

Duane Jackson CEO KashFlow has used the AccountingWeb discussions channel as a way of communicating what he believes are potential insecurities in using Yodlee as a mechanism for obtaining bank data. The title is provocative: Bank feeds, you know they’re dodgy, right? Yodleee is used by Xero and FreeAgent. The article is interesting at a number of levels.

So far, the piece has not been replicated on the KashFlow blog. In other channels I and others have been highly critical of SAP using Forbes’ AdVoice as a way of spreading thinly veiled propaganda. Forbes, like AccountingWeb has a large subscription list. The theory runs that if the content generated by the company prompts a referral which leads to a sale then it has done its job. While there can be no faulting the marketing logic I strongly object to direct content placement. My reasoning is that such articles are almost never fact checked and that uninformed readers may be lulled into believing something that is fundamentally incorrect. It is why I turn down 100% of all inquiries asking to use AccMan space for similar purposes, despite the fact it could represent a lucrative revenue stream. It is an ongoing discussion that I and others have with SAP at the most senior levels and at regular intervals.

I don’t use the term propaganda lightly, especially given its negative overtones. Per Wikipedia:

Propaganda is a form of communication that is aimed at influencing the attitude of a community toward some cause or position.

As opposed to impartially providing information, propaganda, in its most basic sense, presents information primarily to influence an audience.

The other main reason I am not in favour of such pieces is because they almost always sound defensive. If you are competing in the market then most customers want to hear about success, preferably from customers. They don’t want to hear companies putting other competitors to the sword. It may make for catchy headlines but it is rarely effective, despite what marketers might claim. It is a common practice that I warn about on a near daily basis.

It is important to understand that KashFlow is not independent nor unbiased in its position. It is part of a competitive market. It does not for example point out that:

  1. Yodless is a PCI Level 1 Service Provider.
  2. There are no recorded security breaches of individual bank information arising as a result of using Yodlee technology.
  3. That the primary source for the critique is less concerned about Yodlee and more concerned about the way the service is operated by a third party. In this case a financial solution in South Africa.
  4. The primary source itself is guessing about how Yodlee works in the context of the service provided.
  5. Another source referenced says Yodlee’s clients include Barclays, Bank of America and Citibank.

As part of the argument, KashFlow invokes the possible (but as yet unnecessary) loss adjuster view that the manner in which Yodlee is used might represent a breach of bank Ts & Cs and therefore any actual loss by a customer would not be covered by the bank’s insurance. While that may be a theoretical possibility, the facts do not speak to that. This is what analysts and media call spreading FUD – Fear, Uncertainty and Doubt. I would be much more impressed to hear a loss adjuster make that statement.

Gary Turner, MD Xero UK steps in to discuss his company’s use of Yodlee. He points out (among other things) that:

Yodlee isn’t a perfect solution and one day we’d hope to see more banks building their own plumbing to negate the need for third party supplementers like Yodlee. However, given the preponderance of cases where banks use Yodlee themselves – we were recently asked by a UK bank to build a Yodlee connector for them! – I don’t imagine Yodlee will disappear overnight and we’re satisfied that this is the right service for our customers.

He also points out that the primary reason vendors are compelled to use the service is that UK banks do not provide standard interfaces through which services like an accounting system can access the bank data needed to populate the debit and credit. Gary is not an unbiased source either but he does counter with facts rather than leaving questions in the air. For instance, he talks about the number of customers accessing bank information either directly through other technology or via Yodlee.

The fact of the matter is that despite KashFlow’s claims, we don’t know that bank feeds as implemented by any vendors are ‘dodgy.’ We do know that there are risks with all IT but that so far, we have not heard of any breaches arising from these specific arrangements. It is therefore moot. Customers will decide for themselves whether the perceived rather than real risks are something with which they cannot live. In any event, customers are not compelled to use the feed mechanism. That choice, coupled by transparency is welcome.

There is another side to this. KashFlow, in common with many SaaS offerings provides third party access to its systems. We are told to trust that the access third parties are given is secure? Are they any less believable? What do we know of the testing they perform to ensure that third party systems are only doing what they claim or that they cannot manipulate data in an unauthorised manner?

The question for readers is simple: do you believe there is an issue that KashFlow is correct to outline or is KashFlow in need of more adult supervision on the question of FUD?

PS – Coincidentally, I noticed this evening that KashFlow ads pop up on YouTube. (That’s where the illustration comes from.) The video I was watching at the time was for a military exoskeleton demonstration. It seems appropriate :)

Comments on this entry are closed.

StuartJones February 29, 2012 at 4:28 pm

Diane Jackson would say that wouldn’t he?

david_terrar February 29, 2012 at 6:08 pm

 @StuartJones He would (but he won’t like being called Diane) :)

Kofi March 14, 2012 at 3:13 am

Very good article and very lethahy debate.

I would like to take different approach to explain why multi-tenancy is much more than just a DB Architecture .I believe that multi-tenancy is a technology answer to the economic problem SaaS business model faces. “Cost to serve customers” is an extremely crucial metric in building SaaS business. Cost to serve can save or sink SaaS business. In order to meet the demands of the lower Cost to Serve (customers)…. Organization needs to minimize costs involved in Operations, Hardware, and Software in serving customers.

Only way to achieve this is to make sure that each of these resources are scaled and shared across customers thus helping reduce overall cost(to serve) per customers…..Operations Costs: When it comes to reducing operations costs, one needs to consider….Are there processes and procedures which allow ease of management?: Metadata change management/propagation (Orchestration). Is there Central point of control for management (monitoring/correction etc…)?Are there ways to upgrade customers in one fell swoop? Are all customers on the same version of software?How many points of failures are there in the overall deployment, are these failure points across all tenants or are they “on a per tenant” basis? (This could make or break support for SLA. Some one in this discussion recommended creating virtualized environment(Virtual machines) and deploying same package of software to reduce costs… but this will increase operations costs if not done properly(as many points of failures in operations as there are virtual machines) and would make it impossible to meet SLA’s)IS there enough tooling in the architecture to allow for monitoring/measuring performance of all components centrally as well as on exception basis? (This will directly dictate operations personnel cost and what kind of SLA you can provide)Same consideration goes for hardware and software. Just making database shared across tenants in neither going to reduce software cost nor it is going to scale the hardware infrastructure for several thousand tenants.

Only way, is to make sure that almost entire software stack is shared across multiple tenants (UI, Authentication/Authorization mechanisms, Process flows/Process controls, Error handling mechanism, Provisioning, billing etc…) resulting in desired cost/performance scalabilities.There are other aspects involved in SaaS business from the end user prospective.

End users expect to get started with minimal intervention from the vendor providing services… this calls for additional software/application features such as easy UI, integrated billing system, integrated self learning systems in place. This requires for a separate tooling of application stack which is not a must have for on-premise or traditional application stacks.In summary… it is really about Costs, Scalability, SLA for running a SaaS business which dictates the multi-tenancy architecture.

Vish Agashe

Previous post:

Next post: