OnSwipe redirect code

Monday, March 30, 2015

Layman's analysis of an ULIP : Bajaj Allianz Future Gain

Recently a friend of mine asked me whether he should choose to invest in a Mutual Fund or this ULIP named Bajaj Allianz Future Gain. The ULIP salesman have apparently been pestering him a lot to invest in that scheme while I had strongly suggested him to not go with any ULIP at all. In my books ULIPs have a blanket ban. My friend Prabhakar Kudva and Dhirendra Kumar of valueresearchonline.com have given me enough information to realize that combining investment and insurance is not a good idea and ULIPs in India are definitely very bad investment options for almost all.

valueresearchonline.com had been a regular critic of ULIPs back  in 2000s when ULIPs had a free run without any check. In those days ULIPs charged insane charges like 25% to 30% and have literally scammed investors. After a lot of noise was made about this, IRDA finally woke up and put in some nominal rules to regulate this kind of practice. It however left a huge holes in the policy for these insurance companies to exploit. Insurance companies are not so closely watched as the Mutual Fund companies are watched by SEBI and transparency requirements are also lower for insurance companies. As a result ULIPs become very risky options for investors because of the exploitation possibility.

Anyways that was the history. Despite all this gyaan, my friend however wanted me to take a specific look at this particular ULIP - Bajaj Allianz Future Gain.

So I tried to do a quantitative analysis of the same to demonstrate how bad an investment option it is.

NOTE : Professionally I am an engineer and finance is just a hobby for me. So calculations below are as per my understanding and hence should not be taken as serious financial advise.

Bajan Allianz Future Gain plan facts (Source : http://www.bajajallianz.com/Corp/content/endowment/future-gain-web.pdf)

Minimum premium : 25,000/- Yearly
Minimum sum assured : 2,50,000/- (10 * annual premium)
Minimum Policy term : 10 years
Minimum Premium paying term : 5 years
Lock in period : 5 years

Premium allocation charge :
1st year : 5.5.% of Annual premium = 1,375/-
2nd - 5th year : 3.75% of Annual premium = 937.5/- per year. (3,750/- for 4 years)

Average yearly charge = (1375 + 3750) / 5 = 1025

Yearly charges so far = 1,025/-

Policy administration charge :
33.33/- per month increasing at 5% p.a. every month
Assuming this 5% is compunded every month at the end of 5 years this value will be 42.77.
So for the sake of simplification let us take the average of starting and ending value as the monthly dedudction

Average monthly dedudction = (33.33 + 42.77) / 2 = 38.05 =~ 38/-

Yearly policy administration charges = 38 * 12 = 456/-

Yearly charges so far = 1,481/

Mortality charge :
For a person aged 30, charge = 1.34 per thousand sum at risk (Deducted at monthly anniversary a.k.a every month)

Sum at risk = Maximum of [death benefit – regular premium fund value - top up premium fund value, zero]
Death benefit = 2,50,500/-
Regular Premium Fund value will keep changing depending the fund performance.

At beginning for first year = (First premium - charges) = 25,000 - 1481 = 23,519
So sum at risk = 2,50,000 - 23,519 = 226481/-
Mortality charge = 227 * 1.34 = 304

Yearly charges so far = 1,785/-

NOTE : The mortality charges will decrease as you pay more premium and also as the fund gains more value. But to keep things simple taking an average value is acceptable for this calculation and to illustrate the point that ULIPs are not really good options.

So for a yearly premium of 1,785/- you get a life cover of 2,50,000/- for 5 years (assuming you do not want to pay a premium after the mandatory 5 years)

Now consider the Anmol Jeevan - II (822) term plan from LIC.
For a yearly premium of 1,617/- you get a life cover of 7,00,000/- for 5 years (Source : https://www.licindia.in/premium_calculator.htm)

So wouldn't it make sense to separate out investment and insurance? For insurance take a plain term plan and for investment choose a decent ELSS scheme. This way your investment will perform much better and you will also have a much better insurance life cover.

Saturday, February 7, 2015

AJAX for beginners - what it is and how it evolved

Today's websites or web pages are very complex structures involving several components. It can be daunting for a beginner to understand it all at once. To ease the process let's break things down and see how the various pieces fit together.

At the core of web pages is the HTML. It is the language that browsers understand and it is what web developers use to showcase rich content. Without HTML all our web pages would have been simple text files. Now I assume that you are aware of HTML and how it is used in web pages. Another critical piece that works closely with HTML is CSS, but we can skip that one for now.

Plain HTML web pages are pretty dull. They are not really interactive. What they mainly have apart from text are :
  1. Some formatting information which tells the browser how to show the contents.
  2. Some media content like images or videos.
  3. A bunch of hyperlinks which lead to other similar web pages.
  4. In slightly evolved pages there would be forms which allowed a user to send data back to the servers.

It is the third one which helped form this "web" of pages which we call the Internet. How do these links work? Pretty simple actually. Each link typically points to a web page on a server. Whenever a user clicked on a link, the browser would fetch that page, remove the existing page and show the newly downloaded one. Some times the link could point back to the same page in which case clicking on it would just "refresh" the existing page. We all know about the refresh/reload button in the browsers don't we?

There are a few things to note here.
  1. These basic web pages were dull in the sense that they were not interactive. They did not respond to user actions except for clicks on links, in which case the existing web page goes away and a fresh page is loaded.
  2. When a link was clicked the browser would decide to send a request to the server. The web page itself did not have much control on when the request should be made.
  3. When the browser was making a request in response to a link click, there was pretty much nothing you could do with the web page until the request completed. Every request to the server blocked the entire page and if there were multiple requests that had to be made it had to be sequential, one after the other. A fancy technical word to describe this would be "synchronous".
  4. An obvious observation is that the data that came from server in response to request from a browser was HTML, as in the data and information on how to display that data were sent back from the server all the time.

While the fourth point appears as not such a big problem, the first three are definitely limitations.

To work around the first problem browser developers came up with JavaScript. Browser folks told web developers that they can make their web pages interactive and responsive to user actions by writing code to handle those interactions in this new language called JavaScript and including it in the web pages. Web developers could now write different pieces of code to handle different user actions. The browser provided a few functions (aka APIs) in JavaScript which the web developers could use to make changes to the web page. This API is called DOM (Document Object Model). Thus web pages became interactive and responsive.

The second and third limitations still existed however. The only way to request data from server was through links or in case of evolved pages through forms. Also the web page was one single unit. Whenever something had to change the whole page had to be reloaded. Imagine something like that with your gmail page. How would it be if the page refreshed every time you received a chat message or worse every time one of your contacts logged in or out of chat? That would be disastrous. The fate would be similar of something like a sports website in which the small corner showing the score needs to be updated a lot more frequently than the rest.

To solve this some people thought of iframes as a solution. Iframe is a HTML tag inside which you can put another HTML page. Now with this arrangement the inner page could be reloaded without affecting the outer page. So the sports website could now put the score part in an iframe and refresh it without affecting the rest of the page. Similarly gmail could break up its page into multiple iframes (It actually does this in reality, but it also does a lot more than this).

With iframes the "synchronous" problem was somewhat solved. Multiple requests could now be made in parallel from a single web page. However the method of making the request largely remained the same, using links or forms. It was either not seamless or almost impossible to make requests in any other manner, like say whenever user typed something (like Google search). Now let's see what all capabilities we have on top of the basic web pages.
  1. Web pages can respond to user actions. Some code can be executed on various user actions made on different parts of the page.
  2. This code can modify the web page using DOM.
  3. Browsers are now capable of making multiple requests in parallel without blocking the web page.

The browser folks now combined these abilities thereby allowing web developers to make requests to servers in response to user actions using JavaScript. These requests could be made in parallel without blocking the page i.e. Asynchronously. Now when the response came back the same JavaScript code could add the HTML received in the response to the existing page using DOM.

The developers went a step ahead and said "why receive HTML every time? In most cases the formatting or presentation information is already there in the web page. What is needed is only new data or content (For example, in the sports website example, all that is needed is the updated score. Information on how to show that score is already present in the web page). So instead of fetching HTML every time let's just fetch data to make things much faster and efficient". And back then the most popular way of representing data in a structured manner was XML. So developers started receiving data in XML format from the server and using that to update the web page. XML was so popular that browsers added support for automatically parsing XML data received in response to these requests.

This approach of making requests and updating parts of web pages became very popular and was much widely used. Since this was predominantly used to make requests over HTTP (The protocol of the web) to fetch XML data this technology was called "XMLHttpRequest" (Internet explorer called it something different, it probably still does).

What all does this XHR offer?
  1. Making requests "Asynchronously"
  2. Making requests from "JavaScript"
  3. Making requests for "XML"

Put together it forms "AJAX - Asynchronous JavaScript and XML".

Notes :
  1. Several things have been simplified here as this is aimed at people new to web development and Ajax in particular. This should nevertheless give a good starting point.
  2. References to XML should be read as " something other than HTML". Nowadays XML has been largely replaced by JSON because of several advantages.
  3. XMLHttpRequest does not necessarily mean making asynchronous request. It supports making synchronous requests also. But I don't know if there is a good reason to do it. Making a sync xhr will block the entire page until that request is complete. Really don't do that.