How long does the yodlee implementation take?

Question

I’m a non-technical (well, not software. Hardware background) founder who hired a pretty good developer who built a website with a Rails backend and a pretty CSS / HTML interface. our next step is to develop Yodlee integration, and we both want to know how long it will take. He has an assessment that, in my opinion, is reasonable, but would like to receive feedback from the community without biasing answers.

In addition, if someone did the implementation earlier, I would really appreciate your perspective and help!

Answer 1

I have implemented the comprehensive integration of Yodlee to launch LA over the past two years. They built a platform for social gaming and money management. The short answer is that this is tough and dirty work.

The technical aspect of getting your application to communicate with the Yodlee API is not at all complicated (its a pretty standard web service). The following are some aspects that emphasize complexity:

• The hardest part is related to the unknown and the variability of customer data.
• Actually no API documentation
• There are several ways to perform each operation that will return different data.

I have designed and built systems for 15 years and have been good at evaluating projects. We were with Jodle; in fact, we are still dealing with problems. To understand why it is so complicated, you really need to understand what Yodlee is .. it is an aggregator of 10,000 different systems. Now these other systems may be large professional systems such as Bank of America, Chase, ... but they are often small small banks (Bob Bank in Omaha).

When Yodlee communicates with large companies (they are called content services), there is always an api that actually returns good data. But with the little ones, they do screen screening. You can imagine that it breaks all the time. They have a whole team in India that is simply focused on this.

Another problem is data modeling; each of the content services in its source modeled the data differently (different names, different elements, different relationships, ...), but Yodlee, but combined all 10,000 models into one view. What is leaving you is a very bloated model where you can never know or expect to receive a particular data item.

To give you an idea ... there are additional fields about the credit account (apr, loan amount, last payment, ...) outside the standard base'class fields (balance, ...). Although it’s great that you have this data, in practice the number of content services that provide these additional data elements is so low that you cannot really depend on them. I would say that the accuracy of these data elements is very low. All you can really count on is the basic elements (account name, type, balance) and (transaction date, description and type).

Speaking of transactions ... their transaction categorization system is not so good. They clearly took the first approach to this, instead of focusing on accuracy. We have created a whole system for categorizing transactions, which is much more efficient.

A couple of other things: the DAG account testing system is useless; it doesn’t work like real accounts do. It will be much better for you to open 5-10 accounts in different content services and give your developers a username / passwords for testing. The MFA (multifactor auth) system for account security was an endless headache. This is not Jodley’s mistake, her nature of the game. Banks are doing more and more crazy things that add levels of security. Yodlee has an MFA system to compensate for this. At any given time, about 20% of our accounts are erroneous for any reason. For this we have created a whole component.

So what does this mean? Make sure your grades, get ready for pollution. I do not want to install Yodlee at all (except for the lack of documentation); they really solve a difficult problem. There really are other better options.

Answer 2

I run the team responsible for sales and support for the Yodlee API, so the answer may be a little biased.

I saw clients get up and work anywhere from 10 days to 3 months to 6 months. The implementation time depends on the number of fields in the data model used and how you intend to use the data or manipulate it before presenting it to your users.

While the most common data fields, such as account balance or transaction amount, will always be available, Craig is right, as you fall into a wider data model, you will have to code exceptions when there is no data there. Yodlee provides documentation on how often fields will be available to assist in this process. But if you are only going to use the main account and transactional information, you do not have to worry about these difficulties and speed up its implementation.

How you use the data, once you get it from Yodlee, will also play a big role in the time spent on integration. If you are extracting additional data from transaction descriptions or doing something with categorization, then there is more complexity, and it will take more time. If you use many of the as-is fields, then it will be easier.

Another point Craig talked about is additional security issues (multi-factor authentication). Although this section of the API does add some work, we have added documentation around this to make integration easier. In addition, if you encounter any development problems, we provide customers with access to the developer forum, which is controlled by our technical consulting team.