RCS-e includes an amazing feature "End User Confirmation Request" (section 12.3 of the spec ), implementing a new mechanism to communicate with the user about the service and query for confirmation (or not) for actions. In the client UI this might map to, e.g., a pop-up or similar UI element.
The original spec talks about a sample use case, accepting an "extra charge" for a large file transfer. Other RCS-e centered use cases can be thought: terms and conditions acceptance, etc.
But we believe this has the potential to much more, it can be extended to profitable, non-purely RCS-e use cases. With an appropriate API, any screen with RCS-e access can use this for any transaction requiring user confirmation or acceptance. With the carriers as trusted partner, and, of course, charging suitable fees.
In many countries SIM owners are legally identified and RCS-e is backed by the IMS security and AAA framework, the telco can send a "End User Confirmation Request" required by a bank to one of the customers making a credit card transacton to confirm (or to ask to introduce the PIN). With this approach telcos have the tool to become a security masterpiece of online transactions, fits naturally in their role as trusted parties, much more than OTTs are right now.
With an open End User Confirmation Request API, that makes easy to 3rd parties to access this capabilities, carriers can become a provider of "identified confirmations" to lots of services that need better mass market security for their mobile online services such as banking, online ticketing, micropayments...and it could be a new revenue stream generators for carriers. In many forums where the RCS-e pricing is discussed the alternatives are only about end user fees, but there is also the complementary alternative of business models billing 3rd parties for securized and registered transactions, a huge market in the "online" era.
The model is simple. The telco host the platform, and registered 3rd parties can request confirmations through RCS-e (using a simple REST-like API) and pay for them and telcos monetize one of the most valuable assets, subscriber relationship and identity, to provide more security for their own subscriber and helping the ecosystem to build more compelling solutions, win-win-win.
Solaiemes is working on this and will shortly unveil it to the world:
- RCS-e End User Confirmation Request Server with REST API.
- Support of RCS-e User Confirmation Request Server pop-up in the Web Clients served from the RCS Thin Client Server.
- Adding new API calls to RCS Solution Gateway to allow 3rd party developers creating services on top of RCS-e to request "securized" transactions trough the carrier "end user confirmation" service.
the Solaiemes team
Posts
