在“什麼是利率”篇，很多同學第一次理解了利率的APR和IRR的口徑，從此再不擔心上當受騙。這時就有同學問了，利率這麼複雜，額度肯定很簡單吧？畢竟，他就是一個數字，告訴我一共能借多少錢/刷多少信用卡，不是嗎？作爲一個金融小白，這麼理解沒毛病。如果是一枚金融產品這麼想，就太膚淺了。
額度架構
在“助貸業務概覽”篇中，我們知道一個非傳統金融機構（比如螞蟻金服）如果要放貸的話，貸款是由資金方出資的。而監管要求資金方必須要有自己的風控審覈每一筆貸款，這就導致資金方對每個客戶有自己的授信額度。
而類似螞蟻金服這樣的流量方本身，基於自己對客戶的判斷，對客戶也會給一個授信額度。
同時，流量方也可能會把客戶導流到第三方平臺，比如螞蟻金服導流到銀行借款產品，這時第三方平臺也會對客戶有一個額度。
請問，客戶看到的額度，到底是上面哪個額度？這就是爲什麼額度複雜的原因了。
額度評估
額度評估就是業內人士所說的“授信”過程。基於上面提到的三種額度，授信過程可以非常複雜。我們這裏把“出額度”的過程單獨拆出來談，先不說之前會涉及到的授權、身份認證等流程。
根據產品業務形態，用戶通過身份認證後，會將授信要求的資料，傳到自身風控系統、資方風控系統（如有）、第三方風控系統（如有）進行額度評估。
爲了論述全面，我們假設上面3方都涉及，即是一種較複雜的助貸業務場景。爲了表達方便，假設自身風控系統給出的額度爲a，資方爲b，第三方爲c，若a=0則表示自身風控系統拒絕該客戶的申請，以此類推。這裏需要說明一點，合作的資方，和合作的第三方，可能不止一個。因此當下面說到b=0點時候，指所有資方風控系統拒絕。
場景1：a=0
自身風控系統拒絕，則不管b如何，最終用戶額度=c。
場景2：b=0
資方拒絕，則a和c取大。
場景3：c=0
沒有第三方可路由多餘額度，a和b取小。
場景4：a,b,c均≠0
此時，b和c取大。
從上面的過程我們知道額度的確定過程並不簡單，如果再加上放款時的路由規則（這裏暫且不表），就更加複雜了。
額度管理
額度更新
隨着時間推移，以及客戶借款後的行爲表現，客戶的風險情況會發生變化，歷史給出的額度，也需要隨之更新，以及時反映實際風險。
因此每隔一定時間需要定期查詢客戶的業務資料、徵信資料等數據庫，結合風控政策更新額度。也要設置特定事件，一旦發生則出發某個額度更新規則，比如逾期後額度失效等。
更新額度過程用戶是否需要感知，則受多種因素影響，比如是否需要用戶重新授權進行徵信查詢，額度更新後是增加還是減少等。
額度類型
對於額度使用較豐富的產品，可能一個用戶可能存在多種類型額度，比如現金貸和消費貸因爲產品的內在風險差異，額度肯定有所區別。
但不同類型的額度可能存在勾稽關係。比如可以規定所有額度加起來不超過認定收入的22倍，如果超過了怎麼取捨等。
額度運營
一些互聯網公司會通過打卡、抽獎等活動促進產品活躍度，同時給用戶額度獎勵。這種額度獎勵不會超過三位數，額度與客戶的風險狀況匹配。