Kiva / KivaFriends collaboration : Scheduled Repayment Estimates Feature

[Guest]

.

[nuclearspike]

There's a new feature in development called "Scheduled Repayment Estimates" and it is still in its infancy. It needs some UI love, more details, options, filters, stress testing, etc. It will go live in the next release but will only be accessible through a secret link while it's in testing. I'll be sharing the secret link on KF once it's live this week.

The first screen shot is from a sample lender's portfolio (of course, only you can see your own repayment estimations).

1) Along the top, you'll see a bar graph (currently just a line graph which looks a little odd, IMO) which shows the cumulative scheduled repayments by month. Kind of like the bar chart in KivaBank's Lender Analysis tab, but this one is based on real loan amounts, without assuming only $25. It's great to be able to query real data!
2) Down the left side, you'll see the year-month due date for the repayments, the cumulative amount due on that date, and how many individual loans were repaying that month.
3) On the right side, you'll see the break out of all loans for the selected month, sorted by how much they're repaying in descending order. There's a "Notes" column that indicates if the loan is currently delinquent or if it's the loan's final repayment.

When you click on the $ amount on the right (detail) side, it pops up the repayment details for that loan (the Repayment portion of the borrower page when in Advanced View -- shown popped-up in the second screen shot) so that you can see if the delinquency is only because they were off by a couple dollars this month, or if they've been missing every payment from the beginning (and whether the borrower or partner is behind).

The feature comes with a disclaimer. This is using the original scheduled repayments only for it's estimations. It does not try to figure out what impact of past month's pre-payments or delinquency will have on future month's repayments. I have a ton of things on my To-Do list for this feature before I will release it to the masses, but it's functional enough now to give a preview to KF'ers.

Quick Question: How many of you (who will be participating in the beta period) have more than 800 active loans paying back? (You can just PM me if you do.) The reason I ask is that I've put an arbitrary cap on it (it will bail if the user has more than 800 active loans) to prevent it from potentially causing a site slowdown right as we're entering a very busy time for the servers. I haven't implemented detail-results paging yet and prepping 1000's of results for mega-lenders can take a while.

Paul

[RichardF]

Hi Paul,
I think this is a great additional tool, just the type of thing Kiva can do more of, now that you’re on board!

I also want to admit that I read and understood this.

The feature comes with a disclaimer. This is using the original scheduled repayments only for it's estimations. It does not try to figure out what impact of past month's pre-payments or delinquency will have on future month's repayments.

Now that I said I like this tool and I understand it’s underlying design starting point, I also feel it’s important to say this about that.

My primary area of concern about the Kiva platform these days is what I believe to be a number of fundamental weaknesses in its general accounting tools for Lenders.  Using your disclaimer as an example, a simple Lender portfolio summary equation might look something like this for outstanding loans:

Scheduled Repayments – Repayments = Outstanding Loans

The Outstanding Loans amount is shown on the Kiva My Portfolio Overview page.  It’s found by subtracting active loan repayments from what’s scheduled.  For outstanding loans, I believe Kiva should strive for providing Lenders with histories and summaries for these basic elements.  Using your monthly Scheduled Repayments example, two extra columns and one extra row (assuming a Total already is there) might look something like this.

Due	Scheduled	Repaid	Outstanding	Loans
Previous	$XXX.XX	$XXX.XX	$XXX.XX	XXX
2010-12	$190.22	$XXX.XX	$XXX.XX	37
2011-1	$102.41	$XXX.XX	$XXX.XX	17
And so on	$XXX.XX	$XXX.XX	$XXX.XX	XXX
Total	$XXX.XX	$XXX.XX	$XXX.XX	XXX

A table like this for outstanding loans not only shows Lenders anticipated future payments.  It also shows them the portion of their outstanding loans at risk.  A similar Loan Repayments History table for a Lender’s entire Kiva Portfolio would round out the monthly overview quite nicely.

Paul, even though I agree this Scheduled Repayment Estimates feature is a nice step forward, I also would request Kiva move toward providing Lenders with more complete financial reporting tools for their portfolios.

In this example, can you give us an estimate about what it would take, both technically and administratively, for Kiva to implement a basic yet complete Loan Repayments History summary for each Lender?

Thanks again for this great tool for lenders!   

[David2051]

There's a new feature in development called "Scheduled Repayment Estimates" and it is still in its infancy. It needs some UI love, more details, options, filters, stress testing, etc. It will go live in the next release but will only be accessible through a secret link while it's in testing. I'll be sharing the secret link on KF once it's live this week.

Hi Paul,

I really like the idea of us being able to do an actual beta test before something goes live on the site.  It seems to me that it is really bad to have new features go live on the site for all to see when they are still buggy or do not meet the goals and then go through a public process of refinement.  A functional beta test should allow for a much more polished product when it's publicly unveiled, which can only help.

Regarding the UI, I have to say the bar chart on KB is certainly much more attractive than the chart here.  Can you give any more information on what you have in mind regarding additional options and filters for this page?

2) Down the left side, you'll see the year-month due date for the repayments, the cumulative amount due on that date, and how many individual loans were repaying that month.
3) On the right side, you'll see the break out of all loans for the selected month, sorted by how much they're repaying in descending order. There's a "Notes" column that indicates if the loan is currently delinquent or if it's the loan's final repayment.

On the left side, I'd like to recommend a more friendly date format.  ccyy-mm does not seem very helpful to me.  It would be nice if it could be consistent with the way dates are presented on repayment schedules.  Perhaps Jan 2011 or Jan 1, 2011 or something else...

What is the intent of the right side of the screen?  I'm having a hard time figuring out what I would use that for.  I have over 500 repaying loans and that number does not drop off very quickly.  It seems like the server load of preparing the page would be high, particularly if I start clicking on different months much, but then there will be so much data that it would not be useful to me.  It might be interesting if I click on the last few months to see which of my loans are the longest, but otherwise I'm just not seeing the value of this.  What am I missing?

What I have wanted for some time is to see the loans I have that are delinquent, and have them categorized by loans that did make a payment last month, ones that did not make a payment last month, ones that have not made a payment for 2 months, 3 months, etc. with counts for the various categories. I've assumed that would belong on the My Portfolio / Loans  page with the other radio buttons which currently do not include delinquency information.

Do you see that sort of thing developing on this new page?

[AccountAbility]

Basically I agree with Richard, that the underlying accounting needs some work in order to have a solid foundation for various extracts such as you have here.

One thing that I find lacking is I still need to do manual math to find out how much total shortfall a delinquency represents.  It would be very helpful to have the chart (or perhaps the advanced borrower repayment schedule) show how much in total was expected to have been repaid compared to how much in total has actually been repaid to lenders.

Dan

[nuclearspike]

The beta version went live this afternoon. http://www.kiva.org/portfolio/estimated-repayments If you like it, bookmark it, since there are no links to it on the site at this time. (This also means sector is now on the lend tab and the borrower page, thanks Cailin!)

Richard, it sounds like what you're describing would be best implemented as a separate tally. The scheduled repayments is looking into the future, and you'd like to have similar functionality but looking into the past where things like currency exchange loss, delinquency/default amounts, pre-payments, etc are known. In this other feature, let's call it "Past Repayments" for now, it would show past month summaries and stop on the current month. I think combining them would mean that there'd be a lot of empty columns once you pass the current month and rather than trying to have one screen solve both sides, just have two separate screens so that each one can specialize in what it's looking at.

I definitely agree that having the scheduled v. actual amounts, outstanding, +/- difference, defaulted, and currency loss by month's in the past would be very beneficial... and that is already part of the plan... but those numbers make sense for the past... not future... other than to indicate how much ahead or behind your loans are overall (just one number listed, not done by month).

I tagged the feature as "BETA" though if I were to put a version number on it, I'd call it 0.1 -- It has to start somewhere. To David's point about having beta releases as standard practice, when it's a new feature/page, with a separate URL, it's easy to just not link to it or have user groups where only those in the group can access that page. But if it's reworking existing pages, having the site operate with both sets of code for the testers/non-testers becomes problematic for a variety of reasons.

What is the intent of the right side of the screen?

A recurring request from many lenders is for better ways to go inspect what's going on with various loans that are paying back. I agree that when you have a lot of paying back loans, it's a lot to look at. Not everyone lends like that (the vast majority do not), so if you don't find this useful, don't use it. There are many users who have a relatively low number of loans and want to check up on the borrowers they'd spent hours selecting. For me, I have a loan coming due this month that was the largest amount I'd ever lent to a single borrower (now that my teams are not penalized for it anymore), and it only has one repayment. So, having that borrower sorted right at the top keeps my eye on it.

I'm looking at replacing the grid on the right with one that is sortable/groupable (with summary numbers for the group) and filterable at the client-side with AJAX fetching for more data... probably add some more columns as well. So you could choose to only show the delinquent loans, or only the Agriculture loans. Potentially have it switch modes if you have more than a certain number of paying back loans, only give summary results broken out by various methods and in greater detail than what shows down the left side, with the ability to drill into the data more. The reason the interface is so basic is because I don't refine it until I've decided that's how it will stay and I like to be able to play with it to get more ideas. Concerns over date formatting don't come into play until I've decided that I'm keeping that table at all -- I'm thinking that I'd like to make the bar charts vertical and clickable and replace the left-hand table. Not sure yet.

In this example, can you give us an estimate about what it would take, both technically and administratively, for Kiva to implement a basic yet complete Loan Repayments History summary for each Lender?

If you'd like to apply for a position to manage future features, timelines, and development priorities based on estimated labor costs, Kiva is hiring a product manager. http://www.kiva.org/jobs/job-product-manager-consumer-apps  

One thing that I find lacking is I still need to do manual math to find out how much total shortfall a delinquency represents

Agreed! I'm already looking at getting that into the appropriate places.

Paul

[YowieFreak]

The amounts shown as being paid back in future months appear to be slightly lower than I calculate.

I suspect that it is always rounding amounts to the lower cent per month per entrepreneur (and I can understand why that shortcut would be taken) but I'm just looking for confirmation that I am not overlooking something else obvious.


Also, the chart doesn't display for me - but that's probably just my browser.  I assume it appears OK for everyone else. 

[YowieFreak]

P.S. Another issue, possibly again just because of my browser, but the popup repayment schedule just sits in place while I scroll the rest of the page, which means I have no way of scrolling to the bottom part of that schedule.

[nuclearspike]

The amounts shown as being paid back in future months appear to be slightly lower than I calculate.

I suspect that it is always rounding amounts to the lower cent per month per entrepreneur (and I can understand why that shortcut would be taken) but I'm just looking for confirmation that I am not overlooking something else obvious.


Also, the chart doesn't display for me - but that's probably just my browser.  I assume it appears OK for everyone else.  

What browser/OS are you using that causes these issues? To your other question: Yes, as the disclaimer states, it always rounds down to the nearest penny (even if .9 of a penny is expected). The penny distribution is part of the accounting process that runs during actual disbursements and different users will get those pennies at different times (on a per-loan-share basis), all totaling up to the total amount lent over time. For mega-lenders, this down-rounding can have an impact when all are summed together. One lender I tested with who was getting back $33K per month was off by about $50 due to always down-rounding the pennies of their thousands of paying-back loans. To have Kiva run through all of it's accounting procedures into the future per-lender, per-loan for amounts that haven't even been posted (and many times will be different from scheduled anyway) was far beyond the scope of what this was intended to accomplish. I chose under-estimating/over-delivering as the better alternative since the differences would only impact a very small set of users and be fractions of a penny off per loan-share when it did occur.

[Skimmis]

On the left side, I'd like to recommend a more friendly date format.  ccyy-mm does not seem very helpful to me.  It would be nice if it could be consistent with the way dates are presented on repayment schedules.  Perhaps Jan 2011 or Jan 1, 2011 or something else...

dd.mm.yyyy is best ;-)

[nuclearspike]

dd.mm.yyyy is best ;-)

The due date is always 01, the first of the month. Repeating that for each row seemed too much. Users are already confused about the repayments, people think December's repayments mean December 15th, but December's repayments mostly come in on November 15th (the settlement date). I explain this in the disclaimer... but I understand that stating that it's the first of the month may make more users look more closely at how settlements work... The accounting side of all of this gets complex, and forcing users to understand it all before they understand what the estimated repayments will be is part of the challenge of providing a UI that makes sense to users who don't understand settlement dates happening prior to due dates. I tried to cover all of this in the disclaimer to allow those looking for more understanding. I've dealt with issues of lenders not knowing their repayments generally come in 2 weeks prior to what KB states (they believe they won't get repaid until the 15th of the month stated as the due date in KivaBank)... it requires a bit of intimate knowledge of how things are invoiced and repaid that surpasses most users' understanding of how Kiva works. If anyone has better ideas for display of this information (or wording in the disclaimer) please let me know. Most KF'ers understand all of this, but what is the easiest to understand in an interface that is not specifically intended to educate users about this aspect of the system, yet provides ways to understand it, without being confusing to the average user?

Paul