Three part question, three part answer. First, the two easy ones.
Q. Do we have to implement pages in a specific way (modules)?
A. I won't go so far as to say "have to", but the module approach is the one of the major value adds to the DNN framework. This is the most efficient way of developing pages, even if you design your modules so you only have one instance in the entire portal. The real benefit is you only have to worry about developing the whitespace; all the plumbing is done for you. Consider the aspx way. You would create master pages and ultimately get to a point where you are creating just the content part of your page. You can think of your module development as just that content part.
Q. Can DNN work with SSL?
A. Although DNN does not "officially" support SSL, there are many of us who have implemented it. In an eBanking application, you may want to secure the entire site. This is certainly the easiest way to use SSL, but it comes with a performance price. You can also use something like http://www.snowcovered.com/Snowcovered2/Default.aspx?tabid=242&PackageID=4103&search=&pagenumber=0&sortby=&tagid= to provide SSL support for specific pages.
Now for the hard one... (Disclaimer: MY Opinion)
Q. What is the security implication for using it for eBanking?
A. Well, this is a tough one. First of all, I'll say the DNN Core team has done a great job with and continues to enhance all aspects of DNN security. For 99.99% of all sites, including eCommerce sites, I think DNN security is sufficient. That .01% where it may not be appropriate is banking. The only reason I say this is because DNN is Open Source and well documented (a good thing, right?). The trouble is it's not too hard to tell when a site is running on the DNN platform. You are giving hackers a huge head start if they know your infrastructure and table structure. On the other hand, are you sure your developers can write something more secure than what DNN has built in? That's an important decision point you'll have to evaluate. If you do go the DNN route, you'll most likely end up with a blended solution. You could use DNN for the core framework, implement your own authentication provider and write your own modules. If you do this, your security is as strong as what YOU develop, and you are using DNN as it was originally intended, as a FRAMEWORK. Do it this way and you'll get the benefit of great features like skins, the client api and best practice architecture. Then rely on yourself for secure content modules.