Hello Corion,

thanks for your fast reply!

Two points on your comment:
Of course SWIFT messages are quite proprietary but they are the de facto standard concerning bank transactions in Germany (perhaps also Europe). In my opinion we would have a good documentation for this and also the (German Version) of the HBCI specification is quite usable.

Regarding the smart card reader a guy from Deutsche Bank 24 told me that they do support "special" smart card readers and floppy disks. But when writing custom software it does not matter where the key comes from. They only do not give support in case using other key storage media and they are not liable in cases when security advises (as documented in HBCI specs) are not met.

Since for me alone its a far to big project: You really think there ist no chance?

Regarding online accounts other than Postbank I think there are testaccounts avaliable from nearly all banks. I will try to get more information tomorrow.

Greetings from Darmstadt...
Georg

There is no doubt that the SWIFT standard (it has even been made into an ISO standard, 15xxx or something) is the standard for (inter-bank) transactions in Germany, Europe and most likely even beyond - I just doubt that it makes sense for the two types of transaction (money transfer, balance statement) that will be used from the end customer via HBCI to implement the whole stuff that SWIFT needs, as noone will ever be able to use it.

I know that there are test accounts for many german banks, but I haven't felt the need to implement a webscraper for a banking interface that I will never use myself, nor have I felt the lust to deparse the broken Javascript some banks (SEB for example) use as an excuse for navigation.

I can only recommend to you to implement as much as you (personally) need in your interface module, and not to embark on a large head-driven project that will not fullfill anyones particular need. If you (think you) need HBCI, implement as much as you need to get the job done. Until now, there are no HBCI modules on the CPAN, most likely because nobody felt the need to write them or maybe because HBCI was too hard to tackle for the people interested.

Under Win32, Perl can (relatively easy) interface to the HBCI via the Win32::API module, which allows you to load any DLL and use the functions therein.

One potential hurdle I see is, that there is no easy way of testing a HBCI program, as you don't have a server to test against, and testing against your own bank account is rather risky in terms of money.

Personally, I can only recommend using a bank with a tried and true online functionality that suits your way of doing business online - for me, the model provided by the Postbank has been quite enough, as I trust https and PIN/TAN to provide enough security for automating download of my account data and making manual money transfers.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]