some of this dates back to EU finread terminal standard in the 90s ... which identified personal computer end-points as particularly vulnerability ... misc. past posts
http://www.garlic.com/~lynn/subintegrity.html#finread

this was before some disastrous deployment attempts brought personal computer addons into such disrepute (one of the things that USB was designed to handle) ... a few old references:
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#52 more on firing your MBA-less CSO

as implied, the mechanics of how the operations are performed can contribute significantly to the vulnerabilities ... discussed in the old "naked transaction" metaphor blog entries, threads, and posts:
http://www.garlic.com/~lynn/subintegrity.html#payments

and for a little more topic drift ... when there are security solutions that tend to be simple point solutions ... and not provide end-to-end coverage ... leaves enormous infrastructure vulnerability leakage:

Data Protection is Impossible
http://www.cioupdate.com/article.php/3733716

one of the x9.59 financial transaction standards characteristics
http://www.garlic.com/~lynn/x959.html

was not to try and eliminate all the places that information could leak ... but change the paradigm so that such information leakage didn't represent a threat or vulnerability.

re:
http://www.garlic.com/~lynn/aadsm28.htm#41

the issue of encrypted/armored sessions somewhat assumes that the vulnerability are (session) evesdropping attacks. purely session-based protection mechanisms are significantly more vulnerable to end-point compromises

article on this trojan from jan08:

New Trojan intercepts online banking information
http://www.networkworld.com/news/2008/011408-silentbanker-trojan.html

similar trojan from dec07

New Trojan Attacks Clients At Four Worldwide Banks
http://www.crn.com/security/204803106
Sophisticated Trojan loots business bank accounts
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9053018

article from may06 mentioning similar trojan from nov04:

How SSL-evading Trojans work
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.html?s=feature

both SSL and VPN showed up in IETF about the same time. The problems with home personal computers as end-point of VPN into corporate networks was well recognized in the 90s ... the issue was also part of what led to EU FINREAD standard ... much of the design predicated as countermeasure to personal computer vulnerabilities.

somebody that we had worked with on & off over 10-15 yrs had developed encrypted sessions for his own use from home and then introduced it as VPN in gateway committee at '94 IETF meeting in san jose.

about the same time, we were brought in to consult with small client/server startup that wanted to do payments on their server. two people responsible for something they called a "commerce server" ... when we were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
and cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa
they had been at a large rdbms vendor ... old meeting
http://www.garlic.com/~lynn/95.html#13

the client/server startup had this technology they called SSL that they wanted to use with what has since come to be called electronic commerce ... and various aspects of electronic commerce (primarily targeted at hiding credit card numbers) is probably the majority use on the internet today.

we were then brought in to x9a10 financial working group that had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... which resulted in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

part of the work was detailed end-to-end threats & vulnerability analysis ... which identified a whole slew of things other than session evesdropping attacks (some also identified in the EU FINREAD standards work).

the resulting x9.59 financial standard ... armored the transaction ... previously discussed in the various naked transaction metaphor threads
http://www.garlic.com/~lynn/subintegrity.html#payments

which eliminated evesdropping as a threat ... and also eliminated the requirement for encrypted sessions as a countermeasure to fraudulent transactions. the spate of online banking trojans are various work arounds to encrypted sessions ... x9.59 armored transactions eliminates the need to have encrypted sessions ... and therefor the perception that online banking is secure based on encrypted sessions.

Armored transactions are still subject to the integrity of the originating endpoint ... something that the EU FINREAD work attempted to address as compensating process.