I am back in Miami now after a great trip to BarCampBank London 3.
While still fresh in our minds I thought it would be a good idea to start a thread about it as several list members was present.
All in all I'd say it was extremely useful going there putting faces on people from the space. I'm quite excited to see so much going on in Europe and Canada.
I wanted to attend all the tracks as they all sounded interesting, but I will have to summarize the 2 tracks I did go to:
Open Standards:
Firstly we tried to define what we meant by Open Standards and also why we needed new ones.
Most people agreed that simplicity was important and that this will allow creation of both core financial services as well as value added services.
We discussed the 3 standards that were represented at the table. Andreas Pizsa of OpenToken, Nils Toedtman of OpenCoin (welcome on the list Nils) and me pitching OpenTransact.
OpenToken and OpenCoin are both different variations of cash like technologies.
OpenToken servers support essentially 2 operations "join" and "split" to handle all operations. It has the potential of working via SMS and even printed coupons. I'll let Andreas go into more detail.
OpenCoin http://opencoin.org/ is interestingly a new implementation of Chaum's digicash. As far as I understood (Nils please correct me if I'm wrong) it relies more on being online with the mint than Chaum's original idea, which makes sense as we live in an always connected world now. Nils please do introduce OpenCoin on the list.
We agreed that we should work towards having common vocabulary within all 3 standards and work on some level of interoperability between all 3 so one wallet could work with all.
Aric talked about some of the really interesting things they are doing at http://openwallet.org/ using OpenTransact and physical embodiments of OAuth tokens. Very cool stuff and very close to being live.
Identity and Authentication:
We started out trying to work out how identity and authentication works today in financial applications. There are 3 big issues here:
1. At the moment users do not own their identity or data within the financial world. 2. Know Your Customer (KYC) requirements where regulators specify how financial service providers should identify new customers at an often great cost. 3. No good way of opening current financial services to external services. Providing online banking credentials to eg. Mint is just not acceptable.
Identity it was pointed out should not be seen as being always the same.
Ram Banarjee pointed out that there are 3 levels of identity financial apps might use today:
1. Anonymous - the user is not required to login. eg. for public data 2. Pseudonymous - The user is really just identified for the purpose of accessing their information. This is where most web apps fall today. 3. Full - The app needs to know your meatspace identity. Basically name, address, id number etc. The reason for this are almost always for government mandated KYC purposes, but credit institutions also need a way of running credit checks.
We talked about how there might be another level of social network identity that could be potentially very useful in the future. This could potentially be used for both KYC and credit purposes in the future. RapLeaf in San Francisco is actually already doing this for several financial institutions in the US, who use it in addition to their regular credit ranking. Everyone was in agreement that this could provide good benefits if this was done under the authority of the user themselves. (which Rapleaf obviously aren't doing).
OAuth was discussed at length and has the potential to solve all kinds of issues. In particular it allows users to be in charge of sharing their identity and financial data in a controlled revokable way with other services.
I mentioned our discussions on the list here about OpenKYC (see http://wiki.github.com/opentransact/opentransact/know-your-customer and search list archives for more). Briefly this allows local companies to setup a KYC service provider using perhaps an extended version of the Portable Contacts standard. Financial Service Providers would be able to reach international markets by being able to outsource their KYC processes to these local service providers.
This seems to have caught the imagination of quite a few people. I think it was Dave Birch who commented that large established banks probably look at their KYC process and existing customer databases are one of their most important assets, that they wouldn't want to share themselves. Which is also why it would have to be independent service providers doing this in the beginning.
We talked about local currencies who by definition know their customers. So going local is also another way of avoiding the headaches of KYC for small startups in the field. It was also mentioned that Western Union only do KYC on the sender and not on the recipient, which was quite interesting.
John from PayPal mentioned that they have experimental OpenID/OAuth setup for some things. I need to research this myself. He also mentioned that they might be interested in an experimental OpenTransact implementation.
Please do comment. In particular I would like to hear from the other tracks. Like Alternative Currencies and Value Added Services which both sounded really interesting.
> I am back in Miami now after a great trip to BarCampBank London 3.
> While still fresh in our minds I thought it would be a good idea to > start a thread about it as several list members was present.
> All in all I'd say it was extremely useful going there putting faces > on people from the space. I'm quite excited to see so much going on in > Europe and Canada.
> I wanted to attend all the tracks as they all sounded interesting, but > I will have to summarize the 2 tracks I did go to:
> Open Standards:
> Firstly we tried to define what we meant by Open Standards and also > why we needed new ones.
> Most people agreed that simplicity was important and that this will > allow creation of both core financial services as well as value added > services.
> We discussed the 3 standards that were represented at the table. > Andreas Pizsa of OpenToken, Nils Toedtman of OpenCoin (welcome on the > list Nils) and me pitching OpenTransact.
> OpenToken and OpenCoin are both different variations of cash like > technologies.
> OpenToken servers support essentially 2 operations "join" and "split" > to handle all operations. It has the potential of working via SMS and > even printed coupons. I'll let Andreas go into more detail.
> OpenCoin http://opencoin.org/ is interestingly a new implementation of > Chaum's digicash. As far as I understood (Nils please correct me if > I'm wrong) it relies more on being online with the mint than Chaum's > original idea, which makes sense as we live in an always connected > world now. Nils please do introduce OpenCoin on the list.
> We agreed that we should work towards having common vocabulary within > all 3 standards and work on some level of interoperability between all > 3 so one wallet could work with all.
> Aric talked about some of the really interesting things they are doing > at http://openwallet.org/ using OpenTransact and physical embodiments > of OAuth tokens. Very cool stuff and very close to being live.
> Identity and Authentication:
> We started out trying to work out how identity and authentication > works today in financial applications. There are 3 big issues here:
> 1. At the moment users do not own their identity or data within the > financial world. > 2. Know Your Customer (KYC) requirements where regulators specify how > financial service providers should identify new customers at an often > great cost. > 3. No good way of opening current financial services to external > services. Providing online banking credentials to eg. Mint is just not > acceptable.
> Identity it was pointed out should not be seen as being always the same.
> Ram Banarjee pointed out that there are 3 levels of identity financial > apps might use today:
> 1. Anonymous - the user is not required to login. eg. for public data > 2. Pseudonymous - The user is really just identified for the purpose > of accessing their information. This is where most web apps fall > today. > 3. Full - The app needs to know your meatspace identity. Basically > name, address, id number etc. The reason for this are almost always > for government mandated KYC purposes, but credit institutions also > need a way of running credit checks.
> We talked about how there might be another level of social network > identity that could be potentially very useful in the future. This > could potentially be used for both KYC and credit purposes in the > future. RapLeaf in San Francisco is actually already doing this for > several financial institutions in the US, who use it in addition to > their regular credit ranking. Everyone was in agreement that this > could provide good benefits if this was done under the authority of > the user themselves. (which Rapleaf obviously aren't doing).
> OAuth was discussed at length and has the potential to solve all kinds > of issues. In particular it allows users to be in charge of sharing > their identity and financial data in a controlled revokable way with > other services.
> I mentioned our discussions on the list here about OpenKYC (see > http://wiki.github.com/opentransact/opentransact/know-your-customer > and search list archives for more). Briefly this allows local > companies to setup a KYC service provider using perhaps an extended > version of the Portable Contacts standard. Financial Service Providers > would be able to reach international markets by being able to > outsource their KYC processes to these local service providers.
> This seems to have caught the imagination of quite a few people. I > think it was Dave Birch who commented that large established banks > probably look at their KYC process and existing customer databases are > one of their most important assets, that they wouldn't want to share > themselves. Which is also why it would have to be independent service > providers doing this in the beginning.
> We talked about local currencies who by definition know their > customers. So going local is also another way of avoiding the > headaches of KYC for small startups in the field. It was also > mentioned that Western Union only do KYC on the sender and not on the > recipient, which was quite interesting.
> John from PayPal mentioned that they have experimental OpenID/OAuth > setup for some things. I need to research this myself. He also > mentioned that they might be interested in an experimental > OpenTransact implementation.
> Please do comment. In particular I would like to hear from the other > tracks. Like Alternative Currencies and Value Added Services which > both sounded really interesting.
> -- > You received this message because you are subscribed to the Google Groups > "agile-banking" group. > To post to this group, send email to agile-banking@googlegroups.com. > To unsubscribe from this group, send email to > agile-banking+unsubscribe@googlegroups.com<agile-banking%2Bunsubscribe@goog legroups.com> > . > For more options, visit this group at > http://groups.google.com/group/agile-banking?hl=en.
> Thanks Pelle, sounds like there are some exciting opportunities for > convergence of standards and some live services coming soon! :)
> Smiles,
> Josef.
> On 2 February 2010 02:17, Pelle Braendgaard > <pe...@stakeventures.com> wrote: > I am back in Miami now after a great trip to BarCampBank London 3.
> While still fresh in our minds I thought it would be a good idea to > start a thread about it as several list members was present.
> All in all I'd say it was extremely useful going there putting faces > on people from the space. I'm quite excited to see so much going on in > Europe and Canada.
> I wanted to attend all the tracks as they all sounded interesting, but > I will have to summarize the 2 tracks I did go to:
> Open Standards:
> Firstly we tried to define what we meant by Open Standards and also > why we needed new ones.
> Most people agreed that simplicity was important and that this will > allow creation of both core financial services as well as value added > services.
> We discussed the 3 standards that were represented at the table. > Andreas Pizsa of OpenToken, Nils Toedtman of OpenCoin (welcome on the > list Nils) and me pitching OpenTransact.
> OpenToken and OpenCoin are both different variations of cash like > technologies.
> OpenToken servers support essentially 2 operations "join" and "split" > to handle all operations. It has the potential of working via SMS and > even printed coupons. I'll let Andreas go into more detail.
> OpenCoin http://opencoin.org/ is interestingly a new implementation of > Chaum's digicash. As far as I understood (Nils please correct me if > I'm wrong) it relies more on being online with the mint than Chaum's > original idea, which makes sense as we live in an always connected > world now. Nils please do introduce OpenCoin on the list.
> We agreed that we should work towards having common vocabulary within > all 3 standards and work on some level of interoperability between all > 3 so one wallet could work with all.
> Aric talked about some of the really interesting things they are doing > at http://openwallet.org/ using OpenTransact and physical embodiments > of OAuth tokens. Very cool stuff and very close to being live.
> Identity and Authentication:
> We started out trying to work out how identity and authentication > works today in financial applications. There are 3 big issues here:
> 1. At the moment users do not own their identity or data within the > financial world. > 2. Know Your Customer (KYC) requirements where regulators specify how > financial service providers should identify new customers at an often > great cost. > 3. No good way of opening current financial services to external > services. Providing online banking credentials to eg. Mint is just not > acceptable.
> Identity it was pointed out should not be seen as being always the > same.
> Ram Banarjee pointed out that there are 3 levels of identity financial > apps might use today:
> 1. Anonymous - the user is not required to login. eg. for public data > 2. Pseudonymous - The user is really just identified for the purpose > of accessing their information. This is where most web apps fall > today. > 3. Full - The app needs to know your meatspace identity. Basically > name, address, id number etc. The reason for this are almost always > for government mandated KYC purposes, but credit institutions also > need a way of running credit checks.
> We talked about how there might be another level of social network > identity that could be potentially very useful in the future. This > could potentially be used for both KYC and credit purposes in the > future. RapLeaf in San Francisco is actually already doing this for > several financial institutions in the US, who use it in addition to > their regular credit ranking. Everyone was in agreement that this > could provide good benefits if this was done under the authority of > the user themselves. (which Rapleaf obviously aren't doing).
> OAuth was discussed at length and has the potential to solve all kinds > of issues. In particular it allows users to be in charge of sharing > their identity and financial data in a controlled revokable way with > other services.
> I mentioned our discussions on the list here about OpenKYC (see > http://wiki.github.com/opentransact/opentransact/know-your-customer > and search list archives for more). Briefly this allows local > companies to setup a KYC service provider using perhaps an extended > version of the Portable Contacts standard. Financial Service Providers > would be able to reach international markets by being able to > outsource their KYC processes to these local service providers.
> This seems to have caught the imagination of quite a few people. I > think it was Dave Birch who commented that large established banks > probably look at their KYC process and existing customer databases are > one of their most important assets, that they wouldn't want to share > themselves. Which is also why it would have to be independent service > providers doing this in the beginning.
> We talked about local currencies who by definition know their > customers. So going local is also another way of avoiding the > headaches of KYC for small startups in the field. It was also > mentioned that Western Union only do KYC on the sender and not on the > recipient, which was quite interesting.
> John from PayPal mentioned that they have experimental OpenID/OAuth > setup for some things. I need to research this myself. He also > mentioned that they might be interested in an experimental > OpenTransact implementation.
> Please do comment. In particular I would like to hear from the other > tracks. Like Alternative Currencies and Value Added Services which > both sounded really interesting.
> -- > You received this message because you are subscribed to the Google > Groups "agile-banking" group. > To post to this group, send email to agile-banking@googlegroups.com. > To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en > .
> -- > You received this message because you are subscribed to the Google > Groups "agile-banking" group. > To post to this group, send email to agile-banking@googlegroups.com. > To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en > .
I'll try in a day or so to make a summary of the sessions I was in - banking the unbanked (getting money to the unmoneyed) and community currencies - but as I wasn't taking notes, and I was operating on 6 hours sleep in the 3 days before, the notes aren't going to be nearly as comprehensive & useful as yours.
Very good to meet you and all the other suspects.
cheers, Michael
On Tue, Feb 2, 2010 at 1:44 AM, Pelle Braendgaard <pe...@stakeventures.com>wrote:
> I am back in Miami now after a great trip to BarCampBank London 3.
> While still fresh in our minds I thought it would be a good idea to > start a thread about it as several list members was present.
> All in all I'd say it was extremely useful going there putting faces > on people from the space. I'm quite excited to see so much going on in > Europe and Canada.
> I wanted to attend all the tracks as they all sounded interesting, but > I will have to summarize the 2 tracks I did go to:
> Open Standards:
> Firstly we tried to define what we meant by Open Standards and also > why we needed new ones.
> Most people agreed that simplicity was important and that this will > allow creation of both core financial services as well as value added > services.
> We discussed the 3 standards that were represented at the table. > Andreas Pizsa of OpenToken, Nils Toedtman of OpenCoin (welcome on the > list Nils) and me pitching OpenTransact.
> OpenToken and OpenCoin are both different variations of cash like > technologies.
> OpenToken servers support essentially 2 operations "join" and "split" > to handle all operations. It has the potential of working via SMS and > even printed coupons. I'll let Andreas go into more detail.
> OpenCoin http://opencoin.org/ is interestingly a new implementation of > Chaum's digicash. As far as I understood (Nils please correct me if > I'm wrong) it relies more on being online with the mint than Chaum's > original idea, which makes sense as we live in an always connected > world now. Nils please do introduce OpenCoin on the list.
> We agreed that we should work towards having common vocabulary within > all 3 standards and work on some level of interoperability between all > 3 so one wallet could work with all.
> Aric talked about some of the really interesting things they are doing > at http://openwallet.org/ using OpenTransact and physical embodiments > of OAuth tokens. Very cool stuff and very close to being live.
> Identity and Authentication:
> We started out trying to work out how identity and authentication > works today in financial applications. There are 3 big issues here:
> 1. At the moment users do not own their identity or data within the > financial world. > 2. Know Your Customer (KYC) requirements where regulators specify how > financial service providers should identify new customers at an often > great cost. > 3. No good way of opening current financial services to external > services. Providing online banking credentials to eg. Mint is just not > acceptable.
> Identity it was pointed out should not be seen as being always the same.
> Ram Banarjee pointed out that there are 3 levels of identity financial > apps might use today:
> 1. Anonymous - the user is not required to login. eg. for public data > 2. Pseudonymous - The user is really just identified for the purpose > of accessing their information. This is where most web apps fall > today. > 3. Full - The app needs to know your meatspace identity. Basically > name, address, id number etc. The reason for this are almost always > for government mandated KYC purposes, but credit institutions also > need a way of running credit checks.
> We talked about how there might be another level of social network > identity that could be potentially very useful in the future. This > could potentially be used for both KYC and credit purposes in the > future. RapLeaf in San Francisco is actually already doing this for > several financial institutions in the US, who use it in addition to > their regular credit ranking. Everyone was in agreement that this > could provide good benefits if this was done under the authority of > the user themselves. (which Rapleaf obviously aren't doing).
> OAuth was discussed at length and has the potential to solve all kinds > of issues. In particular it allows users to be in charge of sharing > their identity and financial data in a controlled revokable way with > other services.
> I mentioned our discussions on the list here about OpenKYC (see > http://wiki.github.com/opentransact/opentransact/know-your-customer > and search list archives for more). Briefly this allows local > companies to setup a KYC service provider using perhaps an extended > version of the Portable Contacts standard. Financial Service Providers > would be able to reach international markets by being able to > outsource their KYC processes to these local service providers.
> This seems to have caught the imagination of quite a few people. I > think it was Dave Birch who commented that large established banks > probably look at their KYC process and existing customer databases are > one of their most important assets, that they wouldn't want to share > themselves. Which is also why it would have to be independent service > providers doing this in the beginning.
> We talked about local currencies who by definition know their > customers. So going local is also another way of avoiding the > headaches of KYC for small startups in the field. It was also > mentioned that Western Union only do KYC on the sender and not on the > recipient, which was quite interesting.
> John from PayPal mentioned that they have experimental OpenID/OAuth > setup for some things. I need to research this myself. He also > mentioned that they might be interested in an experimental > OpenTransact implementation.
> Please do comment. In particular I would like to hear from the other > tracks. Like Alternative Currencies and Value Added Services which > both sounded really interesting.
> -- > You received this message because you are subscribed to the Google Groups > "agile-banking" group. > To post to this group, send email to agile-banking@googlegroups.com. > To unsubscribe from this group, send email to > agile-banking+unsubscribe@googlegroups.com<agile-banking%2Bunsubscribe@goog legroups.com> > . > For more options, visit this group at > http://groups.google.com/group/agile-banking?hl=en.
I know you meant this as a kind joke, but I'd like to give one of my usual rant because this is a subject I'm very involved with.
My personal view is that ideas have more values when they are shared than when they are kept for oneself.
The whole goal of events like BarCampBank is to put everything on the table and see how we can get more out of what was brought, through cross-pollination and recombination.
I believe that big organizations or startups are not good for implementing the same things. By sharing ideas and then implementing the ones they are best fit to, we're sure that a lot more can be done for everyone. Furthermore, if PayPal gets to implement some of the ideas that were presented, I would think that startups could build a lot of new services thanks to that.
So it is my personal opinion that innovators should never be reluctant to share with bigger organizations. Either these organizations will not be able to implement these ideas, but may possibly then act as partners; or they can easily implement them, then it's better for a nimbler group to let a steamroller develop the market and think about the additional services they'll be able to build thanks to that.
Cheers,
Frederic
On Feb 2, 1:21 pm, "otaku....@gmail.com" <otaku....@gmail.com> wrote:
They can not do that. Nobody can steal this. If enough people implement the protocol, what this essentially means is that we're establishing the exact opposite of what PayPal stands for (centralized, closed system). You get millions of individual "islands" of financial activities, all talking to their relevant neighbors, all with their own banks and payment methods...
On Feb 2, 2010, at 12:21 PM, otaku....@gmail.com wrote:
> I just hope eBay/Paypal don't steal all your great ideas! :-)
> Alex
> On Feb 2, 2010, at 8:52 PM, Josef Davies-Coates wrote:
>> Thanks Pelle, sounds like there are some exciting opportunities for convergence of standards and some live services coming soon! :)
>> Smiles,
>> Josef.
>> On 2 February 2010 02:17, Pelle Braendgaard <pe...@stakeventures.com> wrote: >> I am back in Miami now after a great trip to BarCampBank London 3.
>> While still fresh in our minds I thought it would be a good idea to >> start a thread about it as several list members was present.
>> All in all I'd say it was extremely useful going there putting faces >> on people from the space. I'm quite excited to see so much going on in >> Europe and Canada.
>> I wanted to attend all the tracks as they all sounded interesting, but >> I will have to summarize the 2 tracks I did go to:
>> Open Standards:
>> Firstly we tried to define what we meant by Open Standards and also >> why we needed new ones.
>> Most people agreed that simplicity was important and that this will >> allow creation of both core financial services as well as value added >> services.
>> We discussed the 3 standards that were represented at the table. >> Andreas Pizsa of OpenToken, Nils Toedtman of OpenCoin (welcome on the >> list Nils) and me pitching OpenTransact.
>> OpenToken and OpenCoin are both different variations of cash like technologies.
>> OpenToken servers support essentially 2 operations "join" and "split" >> to handle all operations. It has the potential of working via SMS and >> even printed coupons. I'll let Andreas go into more detail.
>> OpenCoin http://opencoin.org/ is interestingly a new implementation of >> Chaum's digicash. As far as I understood (Nils please correct me if >> I'm wrong) it relies more on being online with the mint than Chaum's >> original idea, which makes sense as we live in an always connected >> world now. Nils please do introduce OpenCoin on the list.
>> We agreed that we should work towards having common vocabulary within >> all 3 standards and work on some level of interoperability between all >> 3 so one wallet could work with all.
>> Aric talked about some of the really interesting things they are doing >> at http://openwallet.org/ using OpenTransact and physical embodiments >> of OAuth tokens. Very cool stuff and very close to being live.
>> Identity and Authentication:
>> We started out trying to work out how identity and authentication >> works today in financial applications. There are 3 big issues here:
>> 1. At the moment users do not own their identity or data within the >> financial world. >> 2. Know Your Customer (KYC) requirements where regulators specify how >> financial service providers should identify new customers at an often >> great cost. >> 3. No good way of opening current financial services to external >> services. Providing online banking credentials to eg. Mint is just not >> acceptable.
>> Identity it was pointed out should not be seen as being always the same.
>> Ram Banarjee pointed out that there are 3 levels of identity financial >> apps might use today:
>> 1. Anonymous - the user is not required to login. eg. for public data >> 2. Pseudonymous - The user is really just identified for the purpose >> of accessing their information. This is where most web apps fall >> today. >> 3. Full - The app needs to know your meatspace identity. Basically >> name, address, id number etc. The reason for this are almost always >> for government mandated KYC purposes, but credit institutions also >> need a way of running credit checks.
>> We talked about how there might be another level of social network >> identity that could be potentially very useful in the future. This >> could potentially be used for both KYC and credit purposes in the >> future. RapLeaf in San Francisco is actually already doing this for >> several financial institutions in the US, who use it in addition to >> their regular credit ranking. Everyone was in agreement that this >> could provide good benefits if this was done under the authority of >> the user themselves. (which Rapleaf obviously aren't doing).
>> OAuth was discussed at length and has the potential to solve all kinds >> of issues. In particular it allows users to be in charge of sharing >> their identity and financial data in a controlled revokable way with >> other services.
>> I mentioned our discussions on the list here about OpenKYC (see >> http://wiki.github.com/opentransact/opentransact/know-your-customer >> and search list archives for more). Briefly this allows local >> companies to setup a KYC service provider using perhaps an extended >> version of the Portable Contacts standard. Financial Service Providers >> would be able to reach international markets by being able to >> outsource their KYC processes to these local service providers.
>> This seems to have caught the imagination of quite a few people. I >> think it was Dave Birch who commented that large established banks >> probably look at their KYC process and existing customer databases are >> one of their most important assets, that they wouldn't want to share >> themselves. Which is also why it would have to be independent service >> providers doing this in the beginning.
>> We talked about local currencies who by definition know their >> customers. So going local is also another way of avoiding the >> headaches of KYC for small startups in the field. It was also >> mentioned that Western Union only do KYC on the sender and not on the >> recipient, which was quite interesting.
>> John from PayPal mentioned that they have experimental OpenID/OAuth >> setup for some things. I need to research this myself. He also >> mentioned that they might be interested in an experimental >> OpenTransact implementation.
>> Please do comment. In particular I would like to hear from the other >> tracks. Like Alternative Currencies and Value Added Services which >> both sounded really interesting.
>> -- >> You received this message because you are subscribed to the Google Groups "agile-banking" group. >> To post to this group, send email to agile-banking@googlegroups.com. >> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
>> -- >> Josef Davies-Coates >> 07974 88 88 95 >> http://uniteddiversity.com >> Together We Have Everything
>> -- >> You received this message because you are subscribed to the Google Groups "agile-banking" group. >> To post to this group, send email to agile-banking@googlegroups.com. >> To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "agile-banking" group. > To post to this group, send email to agile-banking@googlegroups.com. > To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
> I know you meant this as a kind joke, but I'd like to give one of my > usual rant because this is a subject I'm very involved with.
> My personal view is that ideas have more values when they are shared > than when they are kept for oneself.
> The whole goal of events like BarCampBank is to put everything on the > table and see how we can get more out of what was brought, through > cross-pollination and recombination.
> I believe that big organizations or startups are not good for > implementing the same things. By sharing ideas and then implementing > the ones they are best fit to, we're sure that a lot more can be done > for everyone. Furthermore, if PayPal gets to implement some of the > ideas that were presented, I would think that startups could build a > lot of new services thanks to that.
> So it is my personal opinion that innovators should never be reluctant > to share with bigger organizations. Either these organizations will > not be able to implement these ideas, but may possibly then act as > partners; or they can easily implement them, then it's better for a > nimbler group to let a steamroller develop the market and think about > the additional services they'll be able to build thanks to that.
> Cheers,
> Frederic
> On Feb 2, 1:21 pm, "otaku....@gmail.com" <otaku....@gmail.com> wrote: >> Very interesting.
>> I just hope eBay/Paypal don't steal all your great ideas! :-)
>> Alex
> -- > You received this message because you are subscribed to the Google Groups "agile-banking" group. > To post to this group, send email to agile-banking@googlegroups.com. > To unsubscribe from this group, send email to agile-banking+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
> Please do comment. In particular I would like to hear from the other > tracks. Like Alternative Currencies and Value Added Services which > both sounded really interesting.
For the first BCBL session I attended Open Standards of which Pelle already provided a good writeup. In the afternoon I attended the Value Added Services session, so a couple of remarks on that.
In general the discussion centered on consumer access to financial data on purchases held by banks and payment processors. The usual suspects of the web-based personal finances management came up, as well as the current mechanisms to enable third parties to access consumer data (ie, in-house OFX implementations vs using account aggregators such as Yodlee). Some of the more interesting observations (from a personal point of view):
- There is a huge amount of metadata generated for each retail purchase. Unfortunately most of that gets lost or ends up in various systems that are not interconnected; basically it is almost impossible to reconstruct the context of the transaction later. Perhaps the most interesting data is line item level description of the purchase, but such data is only ends up in the merchant's system, and that's the end of the story.
- If more of the context of transactions were accessible, we could do pretty much automated accounting. Primarily this is of interest to small businesses that have formal accounting needs, but have relatively simple finances. The holy grail here would be sort of straight through processing accounting where majority of entries would be posted automatically with no human intervention.
- If you're implementing a personal finance app and let users compare their spending behaviour against other groups based on some similarity, it is important to let the user influence the selection of the reference group. Apparently if you just assign the reference group, then users are likely to reject the conclusions: "I'm not like that group so your conclusions don't apply and are useless."
- We also talked some on mobile payments and banking. M-PESA in Kenya provides payments and banking of sorts to way more people than the "formal" banking system. Another interesting player is Smart Money of the Philippines. Smart is providing quite innovative cards linked to the customer's mobile phone. For example, your card can have multiple identities (personal/corporate) which you switch between using your mobile. Spending limits are also manageable with the phone. If thin you've lost your card, you can temporarily disable it using your phone, and so on.
We concluded with an anecdote on a company that sells TV sets on installment plans. Each sold TV is coin operated: you pay a certain amount, and have the TV operational for the next 4h. Once a month, the company collects the money and you need to have eg 40 quid in the box. Interestingly enough, the TV also works as a savings device. If you've watched enough TV to have deposited over the minimum, you'll get that as a lump sum. Apparently it works for people who otherwise have hard time doing any saving at all.
On Sat, Feb 6, 2010 at 2:36 PM, Tuomas Toivonen <toivo...@gmail.com> wrote: > Pelle Braendgaard wrote:
> Hi,
>> Please do comment. In particular I would like to hear from the other >> tracks. Like Alternative Currencies and Value Added Services which >> both sounded really interesting.
> For the first BCBL session I attended Open Standards of which Pelle already > provided a good writeup. In the afternoon I attended the Value Added > Services session, so a couple of remarks on that.
> In general the discussion centered on consumer access to financial data on > purchases held by banks and payment processors. The usual suspects of the > web-based personal finances management came up, as well as the current > mechanisms to enable third parties to access consumer data (ie, in-house OFX > implementations vs using account aggregators such as Yodlee). Some of the > more interesting observations (from a personal point of view):
> - There is a huge amount of metadata generated for each retail purchase. > Unfortunately most of that gets lost or ends up in various systems that are > not interconnected; basically it is almost impossible to reconstruct the > context of the transaction later. Perhaps the most interesting data is line > item level description of the purchase, but such data is only ends up in the > merchant's system, and that's the end of the story.
> - If more of the context of transactions were accessible, we could do pretty > much automated accounting. Primarily this is of interest to small businesses > that have formal accounting needs, but have relatively simple finances. The > holy grail here would be sort of straight through processing accounting > where majority of entries would be posted automatically with no human > intervention.
> - If you're implementing a personal finance app and let users compare their > spending behaviour against other groups based on some similarity, it is > important to let the user influence the selection of the reference group. > Apparently if you just assign the reference group, then users are likely to > reject the conclusions: "I'm not like that group so your conclusions don't > apply and are useless."
> - We also talked some on mobile payments and banking. M-PESA in Kenya > provides payments and banking of sorts to way more people than the "formal" > banking system. Another interesting player is Smart Money of the > Philippines. Smart is providing quite innovative cards linked to the > customer's mobile phone. For example, your card can have multiple identities > (personal/corporate) which you switch between using your mobile. Spending > limits are also manageable with the phone. If thin you've lost your card, > you can temporarily disable it using your phone, and so on.
> We concluded with an anecdote on a company that sells TV sets on installment > plans. Each sold TV is coin operated: you pay a certain amount, and have the > TV operational for the next 4h. Once a month, the company collects the money > and you need to have eg 40 quid in the box. Interestingly enough, the TV > also works as a savings device. If you've watched enough TV to have > deposited over the minimum, you'll get that as a lump sum. Apparently it > works for people who otherwise have hard time doing any saving at all.
> -- > You received this message because you are subscribed to the Google Groups > "agile-banking" group. > To post to this group, send email to agile-banking@googlegroups.com. > To unsubscribe from this group, send email to > agile-banking+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/agile-banking?hl=en.
