執行yodlee實施需要多長時間？

Question

我是一名非技術性（非軟件，硬件背景）的創始人，他僱傭了一位非常優秀的開發人員，他在Rails和前端使用CSS/HTML構建了一個後臺，功能非常強大。我們的下一步是開發Yodlee集成，我們都想知道需要多長時間才能完成此任務。他有一個我認爲合理的估計，但希望社羣的反饋不會偏袒迴應。

此外，如果有人已經做過實施，我會非常感謝您的觀點和幫助！

Answer 1

在過去的兩年裏，我已經實施了一個複雜的Yodlee集成，用於基於LA的初創公司。他們在其上建立了一個社交遊戲和資金管理平臺。簡短的回答是，這是艱難而骯髒的工作。

使您的應用程序與Yodlee API進行通信的技術方面根本不是困難的部分（它幾乎是標準的Web服務）。以下是一些方面突出困難：

• 最困難的部分是處理未知和客戶端數據的變化。
• 有效地沒有爲API
• 有幾種方式做到每個操作，將返回不同的數據

我一直都在設計和建築系統15年，並在評估項目已經得到了相當不錯的任何文檔。我們和約德利走了一段路;實際上我們仍然在處理問題。 爲了理解爲什麼它如此強硬，你真的需要了解Yodlee是什麼..它是一個10,000個不同系統的聚合器。現在這些其他系統可能是美國銀行，大通銀行等大型專業系統，但他們通常是小型銀行（奧馬哈的鮑勃銀行）。

當Yodlee與大公司（他們被稱爲內容服務）通信時，總是有一個實際返回好數據的API。但對於小孩，他們正在做屏幕抓取。你可以想象這會一直打破。他們在印度擁有一支專注於此的整個團隊。

另一個問題是關於建模數據;來源中的每個內容服務都模擬了不同的數據（不同的名稱，不同的元素，不同的關係，...），但Yodlee將所有10,000個模型組合成一個視圖。這使你留下的是一個非常臃腫的模型，你永遠無法知道或指望獲得某個數據元素。

給你一個想法......超出標準基本類別字段（餘額，...）的信用賬戶（apr，信用額度，最後付款等等）有額外的字段。雖然這聽起來很棒，但是您擁有這些數據，但實際上提供這些額外數據元素的內容服務數量太少，以至於無法真正依賴它們。我會說這些數據元素的保真度非常低。所有你可以真正指望的是基本元素（賬戶名稱，類型，餘額）和（交易日期，描述和類型）。

說到交易......他們的交易分類系統並不好。他們明確採取了廣泛的第一種方法，而不是關注準確性。我們爲交易分類建立了一個更加有效的整個系統。

其他一些事情：DAG帳戶測試系統是無用的;它的運作方式與真實賬戶不同。在不同的內容服務中打開5-10個帳戶併爲開發人員提供用於測試的用戶名/密碼。用於賬戶安全的MFA（多因素驗證）系統一直是無盡的頭痛。這不是Yodlee的錯，它是遊戲的本質。銀行正在做更多更瘋狂的事情，增加安全層。 Yodlee有MFA系統來彌補這一點。在任何特定時間，由於某種原因，我們約有20％的賬戶出現錯誤。我們已經構建了一個完整的組件來管理它。

那麼這是什麼意思？加倍估價，準備好變髒。我不想放棄Yodlee（除了缺少文檔）;他們真的解決了一個難題。真的沒有其他更好的選擇。

Answer 2

我運行負責銷售和支持Yodlee API的團隊，所以響應可能有點偏差。

我已經看到客戶在10天到3個月到6個月的任何地方起牀和運行。實現的時間取決於您正在使用的數據模型中的字段數，以及在將數據呈現給用戶之前如何使用或操作數據。

儘管最流行的數據字段（例如賬戶餘額或交易金額）始終可用，但Craig是正確的，因爲當您進入更廣泛的數據模型時，您將不得不在數據不存在時編寫異常代碼。 Yodlee確實提供了這些字段可用於幫助完成此過程的頻率的文檔。但是，如果您只想使用基本帳戶和交易信息，則不必擔心這些複雜性，並且會加速實施。

一旦您從Yodlee收到數據，如何使用這些數據也將在整合所需的時間內發揮重要作用。如果您從事務描述中獲取更多數據或者正在做分類工作，那麼複雜性會更高，而且需要更多時間。如果您按原樣使用了許多字段，那麼這將更容易。

Craig提到的另一項是額外的安全問題（多因素驗證）。儘管API的這一部分確實增加了一些工作，但我們已經添加了文檔以使集成更容易。此外，隨着任何發展問題的出現，我們可以讓客戶訪問我們的技術諮詢團隊監控的開發者論壇。