The subscriber of a mobile banking deployment would interact with this component of the total solution. Depending on the deployment paradigm, the component may consist of application(s) downloaded to the mobile phone (SIM Toolkit or Java as examples), or in some instances would have no logic on the phone (WAP/xHTML or USSD deployments). This portion of a mobile banking deployment must cater for the user interface and manage the interaction with the subscriber.
Many different security paradigms can also be implemented ranging from security that ius only based on CLI (does the transaction come from the expected phone?), to advanced cryptographic solutions. Sometimes the security deployed utilise very innovative and unique techniques, and sometimes solutions are based on standard, tested security techniques.
It is virtually impossible to deploy this component without some logic on a hosted server in the back office. The hosted functionality must manage versions of deployed applications, as well as menu structures and expected responses. The hosted environment must be able to respond to error conditions (specific to the channel) and should be able to adapt to fault conditions (for instance when a SMS-C is not available or when response times from an application on the phone is slower than expected.
Typically solution providers favour some or other channel technology and their specific solution is based towards the channel technology. Thus, one finds that solution providers favouring Java based channels would have developed security, access management, user interfaces dictated by the functionality and characteristics of Java. It is extremely difficult to develop a channel access layer that is technology agnostic.