Skip to Content

Last time, I wrote that it sounds realistic to implement MI 7.1 on top of SAP Banking Services in order to target young customers. At this stage, I was just thinking about an handheld  application people could use to manage their current account in an user-friendly basis. Instead of going to my eBanking page, I synchronize my Ipod-like with my bank account via the Data Orchestration Engine on a regular basis. Let’s call this feature  miBanking application. Then, I am able to check my account information everywhere without any wireless connection.

This concept was a pure theorical assumption based on the basic concept of creating a BAPI wrapper on top of standard BAPIs : retrieving account balances, getting payment history and so on. There was no need of thinking about a high security concept since such as an application only reads data and the standard functionalities of SA MI 7.1 sounds enough to realize it e.g., non repudiation mechanism.

However, SAP MI 7.1 enables the creation of BAPI Wrappers on top of Enterprise Services (under BAPI Wrapper method definition restrictions) and SAP Banking Services already delivers plenty of ESBundles like the Electronic Bill Presentment and Payment. Won’t it be interesting to think about mobilizing ESbundles?

ESBundle Mobilizing Payments 

In that scenario, customers can imagine going to their supermarket with their miBanking application and instead of using their credit card, they will receive the bill presentment via a dedicated secure protocol, banks and companies agreed on. Then, according to some limit checks (exactly like with credit cards), they will either pay directly by exchanging X.509 certificates with the supermarket or ask for a payment request to the supermarket (Request Payment Device Authorization Service). We can store the payment-related private key in the SIM card itself and probably ask to the customer for a private payment PIN code. In the background the supermarket will check if the payment can be done and the payment will either be accepted or rejected.

Then, during the next device synchronization, the customer will receive an up-to-date information for data consolidation making a merge check between paid and unpaid statements (Payment Consolidation Service) and be able to look at its account details. This sounds very nice in theorie but few additional issues must be analyzed. How can I transform my Mobile Device to a Banking Product?

Let’s assume meBanking Application is defined as a set of Credit Card products within SAP Banking Services. We set overdraft limits, PIN codes and additional payments rules for each Credit Card like an automatic payment acceptance limits check. By extending the Account and Contract Management Service of SAP CRM with the product creation then product replication (via BAPI Wrappers and under product definition restritions) into the DOE, we can assume having a global Enterprise Service. The brand new customer’s card account data object can be merged with the customer’s account contract data object, filtered, then deployed with miBanking Application to the mobile device as a new software component version.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply