Thanks to everyone who sent me an email or left a comment following my earlier post on Social Finance. It turns out there are several applications out there which offer some kind of social financial management functionality, notably Wesabe and Mint (No, not the Web analytics package.. or the credit card!

Wesabe tries to build a community around finance, offering financial tips and groups where members can exchange stories and advice. It also provides a Firefox extension which can screen-scrape your transactional data from a given bank’s internet banking interface for upload into the system - from there you get a greater degree of analytics functionality. In theory, all banks are supported, suggesting some clever data analysis things going on.

Mint is entirely analytics driven, without the groups aspect, and with a much slicker “Web 2.0 style” interface. Rather than using a plug-in to gather data, you hand over your user-name and password, and the web app goes off and imports your data, one would assume using a similar method of screen-scraping, however currently only supporting US-based institutions.

Both of these applications pose an interesting question - would you trust them with not only your financial information, but your login credentials for these institutions?

From a financial institutions perspective, I can’t see any support for these applications. The fact that a customer’s security is being compromised takes a back seat to the fact that said institution can no longer cross-sell products and services whilst a customer is managing their account. In fact, Mint actually analyzes a user’s data and recommends the best credit cards and savings accounts, which may be from a totally different financial institution.

From a marketing perspective, this is a major blow, and nullifies one of the main advantages a financial services institution when it comes to marketing to their customers - the knowledge of spending habits which allows for sophisticated targeting of content and offers. All of this information is now in the hands of the third party and may be being used to sell competing products.

If we look from the customer’s perspective, its great - they are often getting a better financial management experience than the systems provided by their banks and credit card companies, especially when it comes to spend analysis; in addition there is independent financial advice on savings and investments.

The big question however is trust.Mint is not a bank, neither is Wesabe - they are start-ups and they are also not governed by the industry regulation and financial guidelines of the financial provided - would you trust them with your credentials?

I think it is something which I would be somewhat cautious about, considering my credentials would likely be stored in less-secure environment than my financial data, held by my bank.Also, assuming I give my credentials, I wouldn’t really want such a company storing copies of my data. Again, I think its all about accountability in the event of data loss. If say HSBC, Barclays or American Express get hacked and my data is compromised, I would likely have a greater degree of recourse than if, say, cached copies of all my transactions were swiped off the servers of a start-up, whom really I shouldn’t have gave my details too in the first place. My financial providers would probably be sympathetic, but also remind me that I should not be sharing my login credentials - something which could affect liability in the case of fraud.

So, what is the solution?

As a consumer, I want access to my data and the ability to slice and dice it however I wish. If this is provided by the financial institution or a third party, I’m not too concerned, provided that it is both secure and adds value.

I think financial institutions need to be aware of this, and also realize that often outfits such as Mint are in a better position to add the value - be it due to technological competence or because its cheaper to let someone else spend the time developing these capabilities. In addition, if a bank goes of and developers their own version of Mint, it makes the social aspect more difficult to develop, not to mention the fact that we would be looking at silos of data rather than open data - can you imagine American Express allowing Citibank and Bank of America customers to import their account data?

To enable this, the solution is simple - Open API’s to banking platforms. Something which third party developers can use in order to retrieve data in a consistent manner with a well-thought out security model. As well as providing token-based authentication, a Flickr-like model could be adopted, requiring users to log in and authorize specific applications which request access to data. This could be controlled through the standard e-banking interface, adding an extra layer of security and also ensuring that customers know what they could potentially be getting into when they allow their data to be exposed in this manner.Now all we need is for one bank to stick their head out and implement something like this… In fact, there is a great opportunity to establish a standard here , which can be adopted across the industry. Also, an Open API also makes it a lot easier for a financial institution to make data available throughout its website or in other applications such as desktop widgets.We aren’t going to solve the marketing loss quite so easily. This could either mean one of two things - either I need to think some more, or perhaps we are approaching the online channel in the wrong way when we consider cross-sell, especially since we are dealing with a web of data. I would welcome thoughts here.

One of the tools I have been appreciated over the past week or so is something called YSlow, a validator for Steve Sounders Rules for High Performance Websites, built as a plug-in for Firebug. It has got me thinking, thats all very well and good when we talk about mostly static web experiences, but how do they apply to rich internet applications, built using the likes of Flash or Flex.

Many of the performance rules such as consolidating CSS and JavaScript, moving CSS to the top of your document etc. are not really applicable in this case. Whereas some rules such as reducing the number of HTTP requests will always be relevant.

Lets have a look and see if we can produce our own set of performance tips specifically for RIA developers. All comments appreciated!

Performance Tips for Flash/Flex Rich Internet Applications

1. Make fewer HTTP requests in your containing HTML page.
   As the average browser can only make up to 6 concurrent HTTP requests out-of-the-box, it is important that your HTML page is optimized for this. As you will likely be using a JavaScript library such as SWFObject in order to embed your RIA, this functionality will not be executed until the page is loaded, meaning that the SWF file will likely be towards the end of the download queue. Thats fine, unless the browser is tied up with downloading other items… For the end user this means they will spend longer looking at an empty page, which is not a good experience.
   In order to solve for this, one should refer to the wisdom of YSlow.
2. Manage User Expectations.
   The likelihood is that your SWF file is going to be fairly heavy, and take a not-insignificant amount of time to download. This is especially true if you are using the Flex framework within your application. If this is the case, it is absolutely essential that you consider giving the user feedback that something is loading, and how long it is going to take. It prevents abandonment and makes the whole experience seem more responsive.
   Similarly, if at any point an application is required to go off and load more data, similar user feedback should be employed if the response is going to take more than a second.Some would argue that the use of preloaders is indicative of a slow application, that may be true, but a longer perceived load time and unresponsive UI are probably more indicative of a slow application!
3. Prioritize Dynamic Content.
   Its easy to get carried away when building applications, externally loading XML files, CSS files and background images so that pretty much every aspect of your application is configurable by external files, rather than a recompilation. Fantastic, except when we consider that all of these files need to be loaded before the application can even thing about rendering.
   Its worthwhile to make a list of all the data files and graphical assets which your application needs to load pre-render. Prioritize these based on how often each particular item is likely to be updated. Consider relocating some of these assets inside your SWF.Its nice to specify text styles using CSS or XML, but if no-one is likely to change it, then do you need it, especially since this could be relocated to an ActionScript class and potential shave a second or two off load time.
4. Consolidate External Data.
   Calls to external services are expensive, often with a round-trip response time of a second or so, and usually coupled with a second call to a crossdomain.xml file. These are a bottleneck, and there is nothing that can be done here. However, if you are making multiple calls, consider consolidating them by developing a server side component which can make both calls, merge the data and return the result. This reduces the client-side overhead, and lets you manipulate the results on the server side if necessary, making your application feel more responsive.
5. Load Cross Domain files up front.
   If a service call is inevitable, consider loading the crossdomain.xml file up front to avoid delaying your initial service requests.
6. Don’t be afraid to cache data.
   If data is unlikely to go out of date, or if you want your UI to appear responsive, pre-populated with data, then why not cache data on the client? Data can be stored in a local shared object, and retrieved on the next load of the application. This creates the impression of a responsive UI and can save on HTTP requests.
   In the background, its important to set an expires property so that you can manage data refreshes, based on the lifetime of the data in question. Weather information may have a lifetime of an hour or so, whereas a user’s profile information often has a lifetime of at least a few days.If data is secure then this method should not be used, unless in conjunction with encryption, as the shared object is accessible on the user’s filesystem.

(more…)