WO2018115348A1

WO2018115348A1 - Improved cash management service platform

Info

Publication number: WO2018115348A1
Application number: PCT/EP2017/084214
Authority: WO
Inventors: Didier VANDENHAUTE
Original assignee: Pwc Enterprise Advisory Cvba
Priority date: 2016-12-23
Filing date: 2017-12-21
Publication date: 2018-06-28
Also published as: BE1025733A1; BE1025733B1

Abstract

The current invention relates to a computing system carrying out a method to generate an action proposal draft, said method comprising the steps of: (a) receiving requirement data from a corporate user by said server, said requirement data comprising a plurality of transaction banking capability requirements relating to cash management and treasury; (b) processing said requirement data by said server to generate an as-is/to-be analysis draft available to a moderator user, said processing based at least partly on said transaction banking historical data; (c) receiving a modification of said requirement data from said moderator user and/or said corporate user, yielding modified requirement data; (d) processing said modified requirement data by said server to generate request data comprising an RFP (Request For Proposal) and a recipient list, said processing based at least partly on said transaction banking historical data; (e) upon confirmation by at least said moderator user, sending said RFP to a plurality of bank users mentioned on said recipient list; (f) receiving response data by said server from one or more bank users belonging to said plurality of bank users, said response data comprising a plurality of transaction banking prices relating to said plurality of transaction banking capability requirements; (g) processing said response data by said server to generate an action proposal draft available to said moderator user, said action proposal draft comprising one or more of said plurality of transaction banking prices relating to said plurality of transaction banking capability requirements.

Description

I IMPROVED CASH MANAGEMENT SERVI CE PLATFORM

Technical field

The invention pertains to the technical field of corporate cash management. In particular, this disclosure relates to aggregation and analysis of data with the aim of providing advice to corporations and banks with regard to their cash management and treasury.

Background

In the past, corporate interactions with banks tended to follow a non-centralized and non-optimized model of tangled banking flows between corporations (and their affiliates) and their financial institutions (e.g., their banks). In this model, each corporation (or affiliate) and each bank communicated in its own way, often using proprietary communication channels. The complexities and inefficiencies of this model were exacerbated by the significant number of corporations and affiliates, and the significant number of financial institutions with which the corporations and affiliates communicated.

More recently, there has been a transition to centralized payment flows and cash management. US 8,190,504 discloses a corporate payment, liquidity, and cash management optimization service platform that helps meet the need in corporate banking to leverage more of the value of the bank relationship with the corporation. The platform integrates into the supply chain processes of the corporate customer and may provide liquidity forecasting and optimization services. The platform provides a one-to-many model in which the bank serves many corporates with one system to save operating costs and gain economies of scale. In addition, the platform leverages existing bank services, while at the same time providing modular, configurable services in a secure, integrated solution. However, US 8,190,504 lacks a mechanism to keep track of transaction banking historical data, and related, lacks a way to update the transaction banking capabilities and prices relating to said historical data. Moreover, US 8,190,504 does not provide mechanisms to compare transaction banking prices under consideration to quantities calculated from historical data. There remains a need in the art for an improved system for cash management. The present invention aims to resolve at least some of the problems mentioned above. Summary of the invention

The present invention relates to a service platform and related computing system for cash management. Hereby, a moderator user acts as intermediary between a corporate user and one or more bank users, whereby the corporate user is facilitated by the moderator user in the improvement of the corporate user's banking structure. The moderator user, the corporate user and the one or more bank users each have access to said service platform and related computing system by means of separate accounts. Hereby, sufficient authentication security and encryption is assumed present to ensure that none of the users has access to account information belonging to the accounts of other users. The overall goal of said cash management is improving the banking structure of said corporate user. This entails rationalization, e.g., by the reduction of the overall number of banks used by the corporate user for cash management in doing business. By reviewing banking relationships, a significant saving is enabled for corporate users. In the process of reviewing, key concerns for the corporate user include forging long-term partnerships with banks ('relationship' banks), maintaining enough bank diversity to manage counterparty risk and ensure sufficient sources of credit as well as local cash management support.

The present invention is therefore directed to a first objective, concerning the generation of action proposal drafts. The intended recipient of said finalized action proposal is the corporate user. This first objective relates to the reviewing of bank relationships, which is decided upon by said corporate user based on a finalized action proposal delivered by the moderator user. Said finalized action proposal is based at least in part on an action proposal draft that is generated according to the present invention. In realizing the first objective, the present invention facilitates all users involved, and particularly the corporate user and/or the moderator user.

Furthermore, the invention is directed to a related second objective, concerning the generation of bank benchmarking report drafts. The intended recipient of said finalized bank benchmarking report is the benchmarking bank user, i.e. a bank user involved in said benchmarking. This second objective relates to the reviewing of transaction banking capabilities of one or more banks associated with a benchmarking bank user, consisting of a benchmarking of said one or more banks against the market. Said reviewing of transaction banking capabilities is detailed in a finalized bank benchmarking report, which is based at least in part on a bank benchmarking report draft that is generated according to the present invention. Also in realizing the second objective, the present invention facilitates all users involved, and particularly the benchmarking bank user and/or the moderator user. First objective

In a first aspect relating to the first objective, the present invention provides a computing system for cash management, the computing system comprising

- a server, the server comprising a processor, tangible non-volatile memory, program code present on said memory for instructing said processor;

- a computer-readable medium, the computer-readable medium comprising a database, said database comprising transaction banking historical data; said computing system configured for carrying out a method to generate an action proposal draft, said method comprising the steps of:

(a) receiving requirement data from a corporate user by said server, said requirement data comprising a plurality of transaction banking capability requirements relating to cash management and treasury;

(b) processing said requirement data by said server to generate an as-is/to-be analysis draft available to a moderator user, said processing based at least partly on said transaction banking historical data;

(c) receiving a modification of said requirement data from said moderator user and/or said corporate user, yielding modified requirement data;

(d) processing said modified requirement data by said server to generate request data comprising an RFP (Request For Proposal) and a recipient list, said processing based at least partly on said transaction banking historical data;

(e) upon confirmation by at least said moderator user, sending said RFP to a plurality of bank users mentioned on said recipient list;

(f) receiving response data by said server from one or more bank users belonging to said plurality of bank users, said response data comprising a transaction banking capability selection and a plurality of transaction banking prices relating to said plurality of transaction banking capability requirements;

(g) processing said response data by said server to generate said action proposal draft available to said moderator user, said action proposal draft comprising one or more of said plurality of transaction banking prices relating to said plurality of transaction banking capability requirements; characterized in that, said receiving in step (f) comprises the at least partially automated updating of said transaction banking historical data based on said response data, and in that, said processing in step (g) comprises comparing a transaction banking price belonging to said plurality of transaction banking prices to a quantity calculated from or available in said transaction banking historical data.

In a preferred embodiment, said computing system further comprises a corporate user interface and an I DAM server different from said server; wherein said corporate user interface comprises a presentation layer configured for HTTPS-based interaction with a user-related device of the corporate user; wherein said computing system comprises a web API configured for interaction between said presentation layer and a processing part of said computing system; wherein said web API is configured for validating a token generated by said I DAM server; wherein said receiving in step (a) relates to the use of said corporate user interface; and wherein said presentation layer is configured for carrying out the following sub-steps belonging to step (a) and relating to authentication of said user with respect to said computing system:

(a.i) receiving credentials, preferably a username and password, from said corporate user via said HTTPS-based interaction with said user-related device;

(a.ii) requesting said token from said I DAM server based on said credentials; (a.iii) receiving said token from said I DAM server and storing said token;

(a.iv) providing said user with access to the computing system;

(a.v) receiving a portion of said requirement data from said corporate user via said HTTPS-based interaction;

(a.vi) sending a message comprising said portion of said requirement data received in step and said token stored in step to said web API ;

(a.vii) after optional validation of said token, receiving a response of said web API to said portion of said requirement data;

(a.viii) providing said user with said response to said portion of said requirement data. Such an embodiment has the advantage of providing an additional layer of security, which is furthermore integrated with the security already provided by the use of HTTPS. In a further preferred embodiment, said web API relates to a REST API; said presentation layer relates to HTML 5; and said token concerns a JSON web token.

In a preferred embodiment, said comparing of said transaction price to said quantity comprises the comparing of said transaction price to any or any of the following: transaction prices different from said transaction price but also provided in the context of said action proposal draft; recent prices of the corporate user provided in the context of a second action proposal draft different from said action proposal draft; recent prices provided by one or more bank users in the context of a third action proposal draft different from said action proposal draft. Hereby, if required, the information required in the comparison is retrieved from the database comprising the transaction banking historical data.

The computing system and its related use according to the present invention provides several benefits. Overall, said system allows for increased efficiency. The system provides a one-to-many model in which the operator user collaborates with many corporate users and bank users with one system to save operating costs and gain economies of scale. Furthermore, the system provides a modular approach at the level of individual transaction banking capabilities. In addition, the system enables an integrated and secure approach to cash management. A specific example relating to such a system is given below in Example 1 , with reference to Figure 1. By standardizing the processes of receiving requirement data in step (a), reiterating with the corporate user by means of an as-is/to-be analysis in step (b) and (c), sending out an RFP to banks in step (e) and receiving response data in step (f), less resources are spent to attain the intended goal of cash management and the drafting of an action proposal. Importantly, this standardization allows for better facilitation by the system, which keeps track of transaction banking historical data in a separate database that is preferably updated in real-time as several corporate users and bank users are served by it. Hereby, particularly the prices from step (f) are relevant for future use. As such, the actions of the corporate users and bank users result in realtime updates of the database which are preferably visible only to the moderator user for reasons of confidentiality. This is advantageous especially in cases where the moderator user represents a large company collaborating with a large number of corporate users and bank users concurrently, where the update of a quantity in the database relating to a specific transaction banking capability relating to a first corporate user may result in the better processing of a request of a second corporate user different from the first corporate user involving the same specific transaction banking capability. To accomplish the same goal, cash management and action proposal drafting with prior art systems would either result in a whale of a logistic problem, or lead to low quality of the outcome when compared to the outcome enabled by a system according to the present invention.

Another advantage of the present system is the ability to compare transaction banking prices under consideration to quantities calculated from historical data accumulated in the context of previous action proposal drafts. Since transaction banking prices play a key role in the drafting of the action proposal, such comparison allows for important checks of the evolution of said prices over the years. Related, the comparison may also allow to judge whether a given price is excessive in view of historical data. Furthermore, specific benefits for different users of the system according to the present invention can be identified. For a corporate user, said system allows for faster service, reducing the time needed between the providing of requirement data and the eventual receipt of a finalized action proposal from the moderator user. For a moderator user, said system allows for a unified approach for collaborating with a multitude of corporate users and bank users. Importantly, the moderator user is further provided with a knowledge database. For a bank user, said system streamlines the process of responding to a multitude of RFPs separately, yielding an overall reduction of the effort spent in the process. This leads to a higher efficiency per RFP for the bank user involved. Additionally, the bank user may benefit from the system in the role of benchmarking bank user, in a method relating to said second objective, as discussed in detail below.

In a preferred embodiment, the computing system according to the present invention comprises a corporate user interface suitable for display to the corporate user. Hereby, said receiving in step (a) relates to the use of said corporate user interface, said corporate user interface comprising a questionnaire suitable for sequential completion by said corporate user, said questionnaire comprising a plurality of questions regarding cash management and treasury, said questionnaire comprising at least one interdependency between a first and second question belonging to said plurality of questions. For the corporate user, the advantage of an embodiment with such a questionnaire is that it allows for a standardized and reliable means of communicating requirements to the moderator user. Indeed, given that the interface is provided by the system, a more uniform approach can be realized over different requests from the same corporate user. Furthermore, the fact that the interface and the questionnaire are provided by the system enables more reliability, since all preliminary answers of the corporate user may also be stored at the server, either as a means of back-up or as a means of service to the corporate user. Moreover, the interdependency between questions of the questionnaire allows for easier communication with the corporate user. In a preferred embodiment, such interdependency includes the automatic hiding of a given question if the answer to a question preceding the given question points out that the given question is superfluous and need not be asked. In this way, the questionnaire may be automatically tailored to the needs of the corporate user, yielding a better user experience and related faster completion of the questionnaire.

In a further preferred embodiment, said plurality of questions belonging to the questionnaire concerns any or any combination of the following: an estimated yearly turnover, an estimated yearly total bank fee, a detailed unit fee, a country-specific overview of transaction types. Hereby a transaction type is preferably linked to a a specific country. This is advantageous since it enables to take into account the specific requirements relating to each country separately, as required by the general scope of cash management and treasury.

In a further preferred embodiment of the system, relating to said sequential completion of said questionnaire by said corporate user, a sum of two or more quantities provided by said corporate user in response to said plurality of questions is compared to an estimate also provided by said corporate user in response to said plurality of questions, said estimate relating to said sum of two or more quantities. This is advantageous since it provides a means to identify problems with the requirement data as provided by the corporate user in an early stage. In another related preferred embodiment, this is combined with an alert, whereby said corporate user interface is configured to generate an alert for said corporate user when said sum of two or more quantities falls outside a range defined by said estimate and a predefined tolerance level. A key advantage of such a system is the immediate feedback received by the corporate user, without necessitating intervention from the moderator user, yielding a faster and more efficient overall completion of the questionnaire. Examples of such alerts include cases in which a sum of quantities is much larger or lower than an expected value such as the estimated yearly turnover or an estimated yearly total bank fee, which may indicate that correction by the corporate user is needed.

In a further preferred embodiment of the present invention, said computing system comprises a bank user interface suitable for display to the corporate user, whereby said receiving in step (f) relates to the use of said bank user interface, said bank user interface comprising a rendering of a plurality of requests based at least partially on said RFP, said rendering of said plurality of requests suitable for sequential completion by said bank user. An advantage of such a bank user interface with rendering is that it provides bank users with a standardized mode of communicating a response to an RFP, allowing for more efficient handling as more responses are requested via the same system according to the present invention.

In another preferred embodiment, said computing system comprises a user account comprising contact details for at least one of the bank user, the moderator user and the corporate user; and said computer system is further configured to send a notification to said bank user and/or said moderator user and/or said corporate user via said contact details, whereby said notification is triggered by an agenda item and/or deadline relating to said method to generate said action proposal draft. This notification may take on the form of any on-screen message, SMS (short message service), chat message and/or push notification. This has the advantage that a problem with a transaction banking price may be identified in an early stage and may be reported to the user to which said notification is appropriate, allowable and relevant.

Second objective

According to another embodiment relating to said second objective, said computing system is further configured for carrying out a method to generate a bank benchmarking report draft, said method comprising the steps of:

(i) retrieving benchmarking information relating to a benchmarking bank user by said server;

(ii) processing said benchmarking information to generate said bank benchmarking report draft, said processing based at least partly on said transaction banking historical data; wherein said benchmarking information is retrieved in step (i) through any or any combination of: querying said benchmarking bank user; querying said transaction banking historical data. Such a system allows to leverage the data present in the database also for the benchmarking of banks, in the form of a service provided by the moderator user to the benchmarking bank user. Hereby, for the sake of confidentiality, it is important that the information provided to the benchmarking bank user does not reveal details relating to banks. A specific example relating to such a system is given below in Example 2, with reference to Figure 2. In a preferred embodiment, the system according to the present invention is adapted for carrying out both steps (a) to (g) and steps (i) and (ii), relating to the first and second objective, respectively. This embodiment is preferred since the two objectives are related and their joint realization leads to a more effective implementation when compared to systems where both objectives are addressed separately. In an alternative embodiment, said system is adapted only for carrying out steps (a) to (g). In yet another embodiment, said system is adapted for carrying out only steps (i) and (ii).

Use relating to second objective In a second aspect, the present invention concerns the use of a computing system for cash management according to the present invention for generating a benchmarking bank report draft, relating to said second objective. This is advantageous particularly in an embodiment whereby the computing system is configured for carrying out both steps (a) to (g) and steps (i) and (ii). Indeed, in the generation of action proposal drafts relating to the first objective, the system accumulates a multitude of useful data comprising said transaction banking historical data. The presence of this useful data is advantageous in the generation of a benchmarking bank report draft, since it allows for overall better results than what would be obtained by a system according to the prior art, which generates benchmarking bank report drafts without access to data accumulated while generating action proposal drafts.

Further aspects of the invention are discussed in the detailed description of the invention and in the dependent claims.

Description of figures

Figure 1 is a flowchart illustrating a method to generate an action proposal draft according to the present invention.

Figure 2 is a flowchart illustrating a method to generate a bank benchmarking report draft according to the present invention.

Figure 3 shows an example first instance of a project list view of a web application according to the present invention. Figure 4 shows an example second instance of a project list view of a web application according to the present invention. Figure 5 shows an example first instance of a dashboard view of a web application according to the present invention.

Figure 6 shows an example questionnaire creation view of a web application according to the present invention. Figure 7 shows an example second instance of a dashboard view of a web application according to the present invention.

Figure 8 shows an example third instance of a dashboard view of a web application according to the present invention.

Figure 9 shows an example project edit view of a web application according to the present invention.

Figure 10 illustrates a preferred authentication mechanism according to the present invention.

Detailed description of the invention

As mentioned in the summary of the invention, an aspect relating to said first objective of the present invention is the generation of an action proposal draft. The action proposal draft serves as a basis of the finalized action proposal, which is at least partly based on the action proposal draft. The action proposal draft is a document generated as output by the computing system according to steps (a) to (g) of the present invention. The intended recipient is the corporate user. The action proposal draft may be used by the moderator user to generate a finalized action proposal. Particularly, the action proposal draft concerns a preliminary document that may lead up to the finalized action proposal, but typically needs some manual intervention from the moderator user. In the manual intervention, the moderator user employs her/his experience and knowledge of cash management and treasury to amend the contents and structure of the action proposal draft. Hereby, particularly those parts of the action proposal draft that are less susceptible to automation, such as parts relating to strategic decision making, require specific attention from the moderator user in the amending of the action proposal draft. The result of the manual intervention is the "finalized action proposal". This finalized action proposal is the document that is delivered to the corporate user by the moderator user. In a preferred embodiment of the present invention, the finalized action proposal is delivered to the corporate user via said computing system in a separate step that takes place after step (g). In an alternative embodiment, the role of the computing system according to the present invention ends upon delivery of the action proposal draft, and the computing system is not involved in the delivery of the finalized action proposal to the corporate user.

In this document, the "finalized action proposal" refers to a proposal by the moderator user to the corporate user regarding reviewing of bank relationships. The finalized action proposal comprises, amongst others, a list of possible actions for reviewing of bank relationships. It further comprises transaction banking prices. In a preferred embodiment, the action proposal further comprises a transactional price analysis, wherein transaction banking fees as provided by the corporate user are compared to bank replies to the RFP. In a further preferred embodiment, said action proposal further comprises a cash centralization analysis.

Another aspect of the invention relating to said second objective is the generation of a bank benchmarking report draft. The bank benchmarking report draft is drawn in steps (i) and (ii) according to the present invention, and serves as a basis of the finalized bank benchmarking report, which is at least partly based on the bank benchmarking report draft. The intended recipient is the benchmarking bank user. Hence, the relation between the bank benchmarking report draft and the finalized bank benchmarking report is similar to that between the action proposal draft and the finalized action proposal, yet the intended recipient is different. The bank benchmarking report draft concerns a preliminary document that may lead up to the finalized bank benchmarking report, but is in need of some manual intervention from the moderator user. The manual intervention is needed in order to allow the moderator user to exercise her/his skill and knowledge of cash management and treasury. The manual intervention comprises amendments to the contents and structure of the bank benchmarking report draft. The amendments are directed mainly to those parts that are less/not susceptible for automation, such as parts relating to strategic decision making, requiring specific attention from the moderator user. The result of the manual intervention is the "finalized bank benchmarking report". This finalized bank benchmarking report is the document that is delivered to the benchmarking bank user by the moderator user. In a preferred embodiment of the present invention, the finalized bank benchmarking report is delivered to the benchmarking bank user via said computing system in a separate step that takes place after step (ii). In an alternative embodiment, the role of the computing system according to the present invention ends upon delivery of the action proposal draft, and the computing system is not involved in the delivery of the finalized action proposal to the benchmarking bank user. In this document, the "finalized bank benchmarking report" refers to a proposal by the moderator user to the benchmarking bank user regarding reviewing of bank transaction capabilities of one or more banks associated with said benchmarking bank user. The finalized action proposal consists of a benchmarking of said one or more banks against the market. Hereby, the anonymity of data with respect to banks other than said one or more banks is ensured through proper processing of said data.

The terms "cash management" and "transaction banking capability" as used in this document are umbrella terms referring to the effective planning, monitoring and management of liquid/near-liquid resources. They may include at least one of the following:

- Day-to-day cash control and forecasting;

- Bank account structure and interest terms;

- Receipts / collections;

- Payments;

- Short-term investments and borrowings;

- Hedging activities (foreign exchange, commodities, etc.);

- Bank relationship management;

- Liquidity management (cash pooling);

- Trade finance and credit lines;

- Treasury management systems (with interfaces to Enterprise Resource Planning systems).

In this document, the term "quantity" refers to an amount obtained directly or indirectly from transaction banking historical data. Said quantity is used as a reference in the evaluation of a transaction banking price, whereby said transaction banking price is compared to said quantity. Related, in this document, the term "predefined fraction" indicates an allowable excess of said transaction banking price relative to said quantity, whereby the allowable excess is determined beforehand. In a preferred embodiment, the predefined fraction is used to specify a limit, whereby said fraction is a relative measure expressed in percentage, for instance 20%, and whereby said excess is allowable if the transaction banking price exceeds said quantity by no more than 20%. In a preferred embodiment, a transaction banking price that is not allowable is labeled as outlier.

In this document, the term "predefined tolerance level" relates to requirement data received from the corporate user and indicates an allowable deviation of a sum of two or more quantities from a reference value, whereby the allowable deviation is determined beforehand. In a preferred embodiment, the tolerance level is used to specify a range, whereby said tolerance level is a relative measure expressed in percentage, for instance 20%, and whereby said deviation is allowable if said sum of two or more quantities deviates no more than, e.g., 20% from the reference value, by neither being more than 20 % smaller nor more than 20% larger than said reference value. In a preferred embodiment, said reference value is a quantity provided by the corporate user, such as an estimated yearly turnover or an estimated yearly total bank fee.

In this document, "web API" refers to a web application programming interface, a set of functions and procedures that prescribe how the interface with an application is to take place. Furthermore, "I DAM server" refers to an identity and access management server. This relates to the creation, definition, and governing of the utilization and safeguarding of identity information, as well as to the managing of the relationship between an entity such as a user profile and the resources to which access is needed. The term "REST" refers to representational state transfer. The term "JSON" relates to so-called RESTful applications, and refers to JavaScript Object Notation, a format used for exchange of data structures. Hereby, a RESTful API, or REST API, is a method of allowing communication between a web-based client and server that employs representational state transfer (REST) constraints. A JSON web token, commonly abbreviated as JWT is a compact URL-safe means of representing claims, preferably credentials for granting access, to be transferred between two parties. The claims are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS).

In a further preferred embodiment of the system according to the present invention, said corporate user interface comprises a progress bar indicating a progress of said corporate user in the completion of said questionnaire. This may be any graphics- and/or-character-based line or shape indicative of or relating to the relative progress of the corporate user in the completion of the questionnaire. This enhances the user experience for a corporate user, increasing motivation to complete the questionnaire as the amount of remaining work can be better estimated. In a further preferred embodiment, said computing system comprises a means to facilitate the moderator user in the creation of said questionnaire. This leads to a more efficient and more standardized result than with a system according to the prior art. Moreover, questionnaires created within the system are fully compliant by default, whereas questionnaires created outside the system have to be imported, which creates an additional effort (and thus additional cost), and related risk of compatibility problems relating to the import of questionnaires in various file formats. In a further preferred embodiment of the system, said action proposal draft comprises more than one action proposal alternative. Indeed, since the system automatically gathers transaction banking capabilities and transaction banking prices, in a preferred embodiment this automation is used to generate a multitude of action proposal alternatives belonging to the same action proposal draft, wherein the system ensures that all action proposal alternatives are both feasible and cost-effective. This has the advantage that the moderator user is provided with a choice between several possible action proposal alternatives, and may choose, optionally after modifications, to present a selection of the generated action proposal alternatives in the finalized action proposal that is delivered to the corporate user.

The invention is further described by the following non-limiting example which further illustrates the invention, and is not intended to, nor should it be interpreted to, limit the scope of the invention.

Example 1 : method to generate an action proposal draft In an example embodiment, the computing system according to the present invention is a service platform that is configured for carrying out the method 100 illustrated in Figure 1.

In this example, the method 100 is started when the corporate user enters into an agreement with the moderator user to restructure its banking landscape and reduce its banking fees. In the context of method 100, it is the corporation, via its corporate user, that is the customer of the moderator, via its moderator user. The moderator user assists the corporate user in achieving the mentioned objectives according to following steps:

(a) receiving 101 requirement data from a corporate user by said server, said requirement data comprising a plurality of transaction banking capability requirements relating to cash management and treasury, comprising information relating to current pricing and structure;

(b) processing 102 said requirement data by said server to generate an as-is/to-be analysis draft available to a moderator user, said processing based at least partly on said transaction banking historical data;

(c) receiving 103 a modification of said requirement data from said moderator user and/or said corporate user, yielding modified requirement data; (d) processing 104 said modified requirement data by said server to generate request data comprising an RFP (Request For Proposal) and a recipient list, said processing based at least partly on said transaction banking historical data;

(e) upon confirmation by at least said moderator user, sending 105 said RFP to a plurality of bank users mentioned on said recipient list;

(f) receiving 106 response data by said server from one or more bank users belonging to said plurality of bank users, said response data comprising a transaction banking capability selection and a plurality of transaction banking prices relating to said plurality of transaction banking capability requirements; (g) processing 107 said response data by said server to generate said action proposal draft available to said moderator user, said action proposal draft comprising one or more of said plurality of transaction banking prices relating to said plurality of transaction banking capability requirements; characterized in that, said receiving in step (f) comprises the at least partially automated updating of said transaction banking historical data based on said response data, and in that, said processing in step (g) comprises comparing a transaction banking price belonging to said plurality of transaction banking prices to a quantity calculated from or available in said transaction banking historical data.

First, a data gathering phase is performed via a questionnaire in step (a) to identify the current structure and costs of the corporate user, aiming to retrieve information relating to current pricing and structure. Gathered data is then analyzed first by the service platform, to generate an as-is/to-be analysis draft, taking into account the transaction banking historical data available in the service platform. This draft is then analyzed by the moderator user; this is typically done at least partially without the help of the service platform. This analysis yields an as-is/to-be analysis document comprising an initial business case. The findings of the as-is/to-be analysis are presented to the corporate user by the moderator user in a design workshop, intended to share the key findings and take decisions regarding the to-be structure. After this workshop, the decisions taken by the moderator user and/or the corporate user are fed back to the service platform by the moderator user in the form of modifications of the initial requirement, in step (c). In other words, the lessons learned from the workshop are submitted to the service platform in step (c). Handed back to the service platform, the modified requirement is used by the service platform to generate a "Request for Proposal" (RFP) in step (d), which is sent to a selection of bank users in step (e) in order to select the banking partners for the future. The RFP responses received in step (f) are first processed by the service platform to generate an action proposal draft. This is handed over to the moderator user who builds a final business case together with a recommendation, documenting it with a finalized action proposal that is handed over to the corporate user. Example 2: method to generate a bank benchmarking report draft

In an example embodiment, the computing system according to the present invention is a service platform that is further configured for carrying out the method 200 illustrated in Figure 2. The method 200 is intended to generate a bank benchmarking report draft. In this example, the method 200 is started when the benchmarking bank user enters into a project with the moderator user to benchmark the bank's transaction banking services. Bank benchmarks may encompass several dimensions such as business offering, technology, geographical coverage, customer service, and implementation management. The project may be based on a formal agreement such as a contract but may also be based on an informal agreement between the benchmarking bank user and the operator user. At any rate, in the context of method 200, it is the bank, via its benchmarking bank user, that is the customer of the moderator, via its moderator user. The moderator user assists the benchmarking bank user in achieving the mentioned objectives in steps (i) and (ii) listed below. Hereby, the moderator user leverages the knowledge gained, e.g., while serving corporate users according to the method 100. This knowledge encompasses details about each bank's service offering and capabilities, both locally and globally. The method comprises the steps of:

(i) retrieving 201 benchmarking information relating to a benchmarking bank user by said server; (ii) processing 202 said benchmarking information to generate said bank benchmarking report draft, said processing based at least partly on said transaction banking historical data; wherein said benchmarking information is retrieved in step (i) through any or any combination of: querying said benchmarking bank user; querying said transaction banking historical data.

The input for the bank benchmarking, originating from the benchmarking bank user, can come from 2 different sources or can be a mix of both:

- bank replies to RFPs; - banks providing information directly for the purpose of the benchmark.

In the first case, the service platform automatically looks up information in step (i) regarding the most recent responses from that particular bank on the various questions/topics that bank intends to perform the bank benchmarking analysis. The service platform's database is a reliable source since it is updated whenever new RFP answers are submitted on the platform. Hereby, new RFP answers typically take precedence on historical ones on all non-pricing related data. However, the method 200 preferably only takes into account the responses from RFPs in final status. Since the data is highly confidential to banks, the service platform is designed to keep the data private and secure at all times. Data is thereby consolidated to ensure that the benchmarking bank user does not have access to confidential information of competitor banks.

In the second case, the moderator user gives access to the questions/topics for which the benchmarking analysis is being executed to a benchmarking bank user via a graphical interface. Benchmarking bank users only see data related to their own bank and are able to modify them or input new data. All changes made by the benchmarking bank users themselves in step (i) are reviewed and validated by the moderator user. They are preferably not automatically updated by more recent RFPs without review by the moderator user. The data gathered in step (i) leads to the generation of a bank benchmarking report draft by the service platform in step (ii). This draft is handed over to the moderator user to finalize the document and obtain a bank benchmarking report that is delivered to the bank user.

Data within the database relating to method 200 is categorized and hierarchized as follows:

- category (i.e. connectivity);

- product (i.e. Electronic banking system - EBS);

- component (i.e. coverage);

- RFP-relating requirement (i.e. number of supported languages): each 'closed' question of the RFP being an RFP-relating requirement.

For each RFP-relating requirement in the database, the moderator user assesses its level of importance (e.g. basic, value-add or best-in-class). This should be editable within the service platform by moderator users. The output of a bank benchmarking project is said bank benchmarking report. The report compares the bank's offering with that of its competitors/peers group. This report contains data retrieved from the database in step (i) and/or step (ii), ranking the bank on each RFP-relating requirement compared to its peers. The latter ranking is also done using consolidated data, preventing that benchmarking bank users have access to confidential information of competitor banks.

To configure the service platform in the generation of the report draft, the moderator user is able to:

- select which banks to be included in the peer group;

- select which individual category / product / component / RFP-relating requirement to include in the benchmark;

- assess the priority level of each RFP-relating requirement not met by the bank.

Correspondingly, a bank benchmarking report provides a consolidated view of the bank's peer group capabilities. Under no circumstance is the bank able to identify the capabilities of individual competitors from the bank benchmarking report. Typically, the number of other banks involved in the benchmarking is at least three, and preferably five or more, to allow for sufficient anonym ization.

Furthermore, moderator users have the possibility to interact with the service platform also by querying the database, able to build graphs, maps and tables based on data retrieved in step (i), but also from data present in the database and relating to method 100, e.g., country and bank fact sheets data.

Example 3: action proposal draft

The following is an example structure of an action proposal draft, as it is obtained at least partially from the action proposal draft as generated by the system according to the present invention. The action proposal draft may be part of an overall recommendation of the moderator user to the corporate user regarding the to-be banking structure, helping the corporate user in selecting their future banking partner(s). The action proposal draft comprises an analysis of the savings regarding:

• the transactional prices

• the cash centralization

• the new banking structure The savings are calculated per bank but also according to different alternatives with more than one bank being selected for the scope of the countries. The analysis is carried out at least partly by the system.

Transactional prices The transactional price analysis compares transaction banking fees as obtained in step (a) to the actual bank replies to the RFP in step (f). The analysis comprises a list of payment instruments per country, the current unit and total fees, and for each bank having replied to the RFP:

- Proposed unit fee

- Unit absolute and relative difference

- Total fee

- Total savings

All the fees are automatically converted to the reference currency required for the action proposal draft. Total fees per country and per bank are displayed separately. Related, a summary graph showing the current transactional banking charges per country / region / globally versus each bank's new pricing is included.

Furthermore, a scenario analysis on the bank responses is included. This relates to action proposal alternatives, allowing the moderator user to distribute the corporate business to different banks and have an estimation of the total costs and savings. For example, it is possible to compute the total fees when assigning the EMEA region to a particular bank, and APAC to another bank. Scenarios should be based on allocating either regions, countries or bank accounts to different banks.

Cash centralization

This analysis identifies how much cash can be centralized (per currency) and at which cost based on:

- the average cash balance per bank account, which is reported via the questionnaire

- the actual bank's capabilities in terms of cash pooling, which is reported in response to the RFP

- the regulation around cash pooling structures per country

This calculation is executed per bank but also via a scenario analysis, i.e. indicating which country/region is allocated to which bank. The output of this analysis includes one or more graphs, such as a graph showing the impact of the cash centralization on a map of the world (as-is situation versus to-be based on different scenarios).

Banking structure The cost of the new banking structure comprises different elements:

- Bank account maintenance costs

- Cash pool costs

- Bank communication cost (depending on the communication channel and the number of users)

- Reporting costs

All the as-is costs can be computed from the information in the initial questionnaire and its related sections, based on for example the following:

- Maintenance fees from a "Bank accounts" section

- Cash pooling fees from the "Bank accounts" section

- Electronic banking system (EBS) fees from a "Channel and formats" section

- Reporting fees from the "Channel and formats" section

In order to compute the "to-be" costs based on each bank's proposed pricing, a new structure must first be devised within the solution. This new structure should allow the user to specify the following: - Number of accounts in each currency per entity and country

- Number of EBS users per entity and country (or other communication channels)

- Reporting needs for each account

- Cash pooling needs for each account or for a group of accounts within a country

Based on this structure, the fees associated to the to-be banking structure are calculated. These fees are provided both in a table and in a graph, showing the current fees (per category) and the fees based on the bank responses to the RFP. The fees computation can vary from bank to bank, some charging EBS fees per user while others charge per country.

Similarly as for the transactional banking fees, a scenario analysis on the bank responses is included, by distributing the business to various banks. Business case

The action proposal draft also includes a business case. Said business case is built based on the three previous items: transaction banking fees, cash centralization and banking structure. It summarizes the fees and savings of each item per bank and region/country, and for any selected scenario. It is displayed by means of one or more graphs showing the current fees and each bank fees proposal.

Example 4: example web interface

Figure 3 to 9 show examples of web interfaces of a web application, illustrating several aspects of the present invention. The web application is primarily intended for the moderator user and the admin user, with full access, and also for the corporate user, with specific access to relevant modules, views and interfaces of the application.

Hereby, the admin user preferably is a moderator user with additional privileges and edit rights not available to all moderator users. The bank user also has limited access to the certain interfaces relating to the reply to RFP. Figure 3 to 9 illustrate merely some of the views that may be useful in the implementation of the present invention as web application.

The web application is accessible via a generic web browser with a title bar 310 comprising an address bar 311 allowing to enter a URL with well-known formatting, e.g. https://address.net. The transfer protocol in this example is https, allowing secure access with encryption of data entered and received via the web interface.

In the embodiment illustrated in Figure 3-9, the URL does not change depending on the view of the web application and/or the progress phase of the projects that are displayed. In an alternative embodiment, the URL may change depending on which view of the web application is requested and/or depending on which phase of a given project is reached.

The web application is only open to registered users. Authentication is credential- based, the credentials consisting of the username and a password. These credentials may be entered in a separate log-in view (not shown). For each of the instances/views of Figure 3-9, the web application view includes a header bar 320. The header bar 320 comprises a home button 321 and a view-related title zone 322 that relates to the title of the web application view that is currently being shown. Furthermore, the header bar 320 comprises a user-name-indicating zone 323, indicating the user name corresponding with the credentials used for login, and a system settings zone 324, with a selectable system settings icon.

Upon selection of the home button 321, the user is led to the project list view 300, 400 of the application. The project list view 300, 400 is displayed after the user has successfully logged in. Figure 3 and 4 show a first instance 300 and a second instance 400 of the projects list view 300, 400 of the web application. The project list view is provided with a project toolbar 410 which is displayed on top of the screen and is visible when the top of the list is displayed, as in Figure 4, and not visible as the user scrolls down for further projects in the list, as in Figure 3. The features and appearance of the project toolbar 410 are dependent on the user profile, and hence differ depending on the type of user profile. For instance, an admin user may be the only user profile type that is allowed to create a new project, which may correspond to the inclusion of a corresponding feature in the project toolbar 410 (see also below).

The project toolbar 410 comprises a project search window 411 that allows to perform a search based on, e.g., the project name or the company name. The project toolbar 410 further comprises a sorting-related dropdown menu 412 that allows for the options of sorting the projects by creation date, next deadline, alphabetically by company name, alphabetically by project name. As can be seen, in the example of Figure 3 and 4, projects are sorted by creation date 345. For a certain class of users, preferably each admin user and/or moderator user, the project toolbar 410 also comprises a project status dropdown menu 413 that allows the user to filter projects by their status, displaying only projects which status is either "Ongoing", "Closed" or "Cancelled". Finally, the project toolbar comprises a new project zone 414 with a selectable "+" (plus) icon, which is preferably visible only for admin users. Upon selection thereof, the user is led to a project creation view (not shown). The project creation view lets a user input details regarding a new project; the project creation view is similar to the project edit view 900.

The project list view 300, 400 displays different project items 331-335 in the project item zone 330. For each project item 331-335, a total of ten items is indicated. Particularly, each project item 331-335 comprises the project name 341, the current project phase 342, an indication of the next deadline (if any) 343, preferably equal to the next project phase date (if any), the project status 344, the creation date 345, the company name 346, an indication of main users if applicable/known 347, the group treasury location 348, the headquarters location 349 and a dashboard-related zone 350 with a selectable dashboard-related icon. Hereby, the main users may relate to moderator users that are assigned as contact persons for the given project. The current project phase 342 is displayed in text along with a ring-shaped icon illustrating the relative progress on a circular scale. From this ring-shaped icon, it is clear that project item 331, with current project phase 342 "Bank selection", is in a further or later phase than project item 332, with current project phase 342 "Data gathering". Finished projects are visually recognizable with a completed ring for the current project phase 342, leading to the absence of a next deadline 343.

Upon selection of the dashboard-related icon in the dashboard-related zone 350, a dashboard view 500, 700, 800 is displayed. Hereby, Figure 5 relates to a first instance 500 of the dashboard view relating to a first date of viewing, whereas Figure 6 relates to a second instance 600 with a second and later date of viewing, and Figure 8 relates to a third instance 800 with a third and even later date of viewing. Figure 5 shows a first instance of the dashboard view 500 for Project A, as it is obtained by selecting the dashboard-related icon of the project item 332 as it is displayed on Figure 3, with current project phase 342 being "Data Gathering". The dashboard view 500, 700, 800 comprises a dashboard tab bar 510 with selectable first tab 511 "As-is analysis" and selectable second tab 512 "Bank selection". The dashboard view still comprises the header bar 320 and now, in the case of a moderator user, further comprises a selectable modify button 326; upon selection, the user is lead to the project edit view 900 of which the details are provided below. The dashboard view 500, 700, 800 further comprises a project phase timeline 520 comprising multiple project phase dates 521-526. The project phase dates 521-526 are in a direct relation to other parameters of the web application, as the current project phase 342 as indicated in Figure 3 and 4 preferably relates directly to these dates, and is more preferably a direct function of the comparison of the current date (i.e. the date on which the user is using the application) with the project phase dates 521-526.

The project phases 342 and project phase dates 521-526 are defined through project modifications. Not all dates need to be set, and hence all are optional. In the present example, the first, second and sixth project phase dates 521, 522, 526 are considered to be defined when the dashboard view 500 is displayed. The other project phase dates 523-525 are undetermined and may or may not be determined at a later time in the course of the project. A first project phase date 521 concerns the kick-off date, 31/10/2017 in the example. The second project phase date 522 concerns the data gathering deadline, 30/11/2017 in the example. The sixth and last project phase date 526 concerns the final business case deadline, 28/12/2017 in the example. The latter corresponds to the current phase of the project, wherein the project is already defined, but a questionnaire is yet to be created and presented to one or more banks to enable bank selection. Hence, the dashboard view 500, 700 and 800 comprises a tab toolbar 510 comprising a first tab 511 "As-is analysis" relating to all aspects of the as-is analysis, such as questionnaire creation, and a second tab 512 "Bank selection" relating to the selection of banks.

The first 511 and second 512 tab are selectable by the user. In dashboard view 500 and 700, the first tab 511 is selected; in dashboard view 800, the second tab 512 is selected. Hereby, the dashboard view 500 comprises a tab-related screen zone 530 comprising a selectable button for creating a questionnaire. Upon selection, the web applications displays a questionnaire creation view 600 of which the details are given below. Once created, the questionnaire may be issued and the web application displays the dashboard view 700 of Figure 7. The dashboard view 500 further comprises the second tab 512 "Bank selection". Upon selection of this tab, an altered view is displayed (not shown) wherein the tab-dependent screen zone comprises a selectable button (not shown) "Create an RFP"; upon selection, the creation of an RFP is initiated.

Upon selection of the button for creating a questionnaire, the questionnaire creation view 600 of Figure 6 is displayed. The questionnaire creation view 600 comprises the header bar 320 which now further comprises a project-related screen zone 327 which leads back to the project list view 300, 400. The header bar 320 comprises a project- related screen zone 327 referring to the title of the project and the company name for which a questionnaire is being created. The questionnaire creation view 600 further comprises a template sidebar 610, displaying several available templates 611-614 which can be modified via the settings-related item "Template - Corporate questionnaire" (see below), whereby the latter settings-related item is only available to the admin user. In this view, currently the template "Template Plus" 611 with last edit date 24/11/2017 is selected, and the corresponding details are available for selection in the template details screen zone 620. The template details screen zone 620 comprises a plurality of sections 621-624 and further sections (not shown). Each comprise a dropdown menu button 630 for displaying a list of questions and a selection box 640 for indicating which of the sections included in the template are to be included in the questionnaire that is to be created. A confirmation button 650 allows to carry over the selected sections to the questionnaire that is being created.

Figure 7 shows the dashboard view 700 after a questionnaire is created. In this phase, the answers to the questionnaire have been entered by the corporate user via an appropriate interface (not shown). These answers are now due to be analyzed by the moderator user. The dashboard view 700 comprises the tab-related screen zones 710, 720, 730. The tab-related screen zone 710 relates to the issuance of the questionnaire and comprises an indication of the publication date 711 of the questionnaire, as well as a selectable button 712 to allow a view (not shown) on the questionnaire structure. The tab-related screen zone 720 relates to questionnaire completion. The tab-related screen zone 720 comprises an indication 721 of the number of questionnaires that have already been received by the web application, as well as the total number of questionnaires to be expected. The tab-related screen zone 720 further comprises a selectable button 722 for importing and exporting answers sorted by entity via a separate view (not shown), as well as a selectable button 723 for importing and exporting answers sorted by category (e.g. "payments and collections", "card collections", "corporate credit cards", payment & reporting channels") across different entities via another separate view (not shown). Hereby, said category corresponds to one of the sections 621-624 selectable in the template details screen zone 620. The tab-related screen zone 730 relates to the reporting of the answers of the questionnaire, whereby the web application allows to generate an output file, preferably a spreadsheet output file. Hereto, the tab-related screen zone 730 comprises a dropdown menu 732 with options "consolidated questionnaire" 731 along with other options relating to different reports that are available (not shown), as well as a selectable button 733 for generation of the output file.

Figure 8 shows the dashboard view 800 where the questionnaires have been completed and their answers analyzed, and the bank selection phase is ongoing. RFPs have been issued and sent to the banks, and the completion of the RFPs is awaited. Accordingly, the project phase timeline 520 now comprises a date indication also for the fourth project phase date 524 relating to the business case deadline, 11/12/2017 in the example, and the fifth project phase date 525 relating to the bank selection deadline.

For the dashboard view 800, the second tab 512 is selected. Accordingly, the dashboard view 800 comprises the tab-related screen zones 810, 820 and 830. The tab-related screen zone 810 relates to the RFPs that have been issued, comprising multiple screen zones 711, one for each RFP, with indication of the RFP title, "06.11 RFP" and "RFP2" in the example, the due date for completion by banks, a selectable view button for opening the RFP structure, and a dropdown menu to manage the RFP status. Hereby, for published RFPs, the status is no longer editable, whereas RFPs in draft may be set to "draft" mode (not shown) or to "ready for publication" mode (not shown). The tab-related screen zone 820 comprises an indication 821 of the number of answers to RFPs that have already been received by the web application from the bank, as well as the total number of answers to RFPs to be expected. The tab-related screen zone 820 further comprises a selectable button 822 for opening the answers to the RFPs via a separate view (not shown). The tab-related screen zone 830 relates to the reporting of the answers of the RFPs, whereby the web application allows to calculate various types of reports. The type of report may be chosen by means of dropdown menu 831, allowing the choice for e.g. "Pricing benchmark" or "Pricing comparison". Furthermore, the tab-related screen zone 830 comprises a selectable button 832 for initiating the generation of the report according to the chosen type. Upon selection, a separate view (not shown) allows to enter parameters relevant to the type of report. In case of "Pricing benchmark", this may for instance relate to the annual turnover and the RFP to which the benchmark relates.

Figure 9 illustrates the project edit view 900, which can only be viewed by moderator users. For these users, the project edit view 900 is reached by selecting the modify button 326 in the dashboard view 500, 700, 800. The project edit view 900 comprises a project edit sidebar 930 with selection of various options that result in different data being shown in the first 910 and second 920 option-related screen zone. In this example, the option "Project information" is selected, with corresponding contents of the option-related screen zones 910, 920 as shown. The first option-related screen zone 910 comprises data entry windows for the project name 911, the project start date 913, the project status 914, the preference currency 915, the project password 916 and the data collection period 917, as well as an indication of the contact persons 912 relating to the moderator user. The project phase dates 521-526 can be entered via the date entry windows 921-926 in the second option-related screen zone 920. A selectable next button 940 leads to another option-related screen zone (not shown), i.e. the one associated with the option "Company information" in the project edit sidebar 930.

Finally, selecting the system settings icon leads to a dropdown menu of settings- related items being displayed. Examples of settings-related items as they are displayed to admin users are "Country", "Region", "Currencies", "Banks", "Standard transaction", "Local transaction", "Template - Corporate questionnaire", "Template - RFP In-country questionnaire", "Template - RFP Generic Questionnaire", "DWH refresh", and "Log out". To other users, less settings-related items are displayed; for instance, to corporate users and bank users only "Log out" is displayed. Selecting "Country" results in a list of countries being displayed (not shown); for each country, certain general properties are displayed. These properties may be edited via the web interface (not shown) and relate to e.g. the country name (e.g., Belgium), the country code (e.g., BEL), the Currency (e.g., EUR), the region (e.g., Europe), the possibility (y/n) of a domestic cash pool, and the possibility of a cross-border cash pool. Furthermore, the services provided by means of the web application, i.e. the services supervised by the moderator user, are displayed in relation to the given country only if they are active. The settings given in this view result in changes for each of the projects handled by the web application, i.e. each project that is listed in the project list view. This holds true also for several of the other settings-related items "Region", Currencies", "Banks", "Standard transaction" and "Local transaction". For instance, selecting "Region" allows to set several parameters on a level above countries, such as one or more continents (e.g. Europe, EMEA), whereby a parent region (e.g., EMEA for Europe) may be indicated if applicable, and whether (y/n) services are active in the given region. And selecting "Currencies" allows to enter currencies and their names, activity (y/n), exchange rate and the date of the last exchange rate update.

The settings-related items "Template - Corporate questionnaire", "Template - RFP In- country questionnaire" and "Template - RFP Generic Questionnaire" relate to the editing of templates. Once entered in the system, these templates may then be reached from other views of the web application, such as the template sidebar 610 in Figure 6, displaying several available templates 611-614 which can be modified via the settings-related item "Template - Corporate questionnaire".

Example 5: example authentication Figure 10 illustrates another aspect of the invention relating to authentication of the user with respect to the computing system. In the following, like reference numerals designate corresponding parts in Figure 10. In this example the user 1 concerns the corporate user; however, this may equally concern the moderator user or the bank user. The example may relate to the system according to claim 1 but may also relate to another system. In its broadest sense, according to another aspect of the present invention which is not intended to limit its scope in any way, the invention provides a computing system that comprises a server, a user interface, preferably a corporate user interface, and an I DAM server 4 different from said server; wherein said user interface comprises a presentation layer 2 configured for HTTPS-based interaction with a user-related device of the user 1, preferably the corporate user; wherein said computing system comprises a web API 3 configured for interaction between said presentation layer 2 and a processing part of said computing system; wherein said web API 3 is configured for validating a token generated by said I DAM server 4; wherein the use of said user interface relates to the receiving and/or sending of data between the user and the computing system and preferably relates to said receiving in step (a); and wherein said presentation layer 2 is configured for carrying out the following steps, preferably but not necessarily belonging to step (a), that relate to authentication of said user 1 with respect to said computing system:

(a.i) receiving 11 credentials 5, preferably a username and password, from said corporate user 1 via said HTTPS-based interaction with said user-related device;

(a.ii) requesting 12 said token 6 from said I DAM server 4 based on said credentials 5;

(a.iii) receiving 13 said token 6 from said I DAM server 4 and storing said token 5;

(a.iv) providing 14 said user 1 with access to the computing system; (a.v) receiving 15 a portion of said requirement data from said corporate user via said HTTPS-based interaction;

(a.vi) sending 16 a message comprising said portion of said requirement data received in step (a.v) and said token 6 stored in step (a.iii) to said web API 3; (a.vii) after optional validation 170 of said token 6, receiving 17 a response of said web API 3 to said portion of said requirement data;

(a.viii) providing said user 1 with said response to said portion of said requirement data.

Likewise, the invention provides the related method according to steps (a.i)-(a.viii) , whereby the means needed to execute the method, i.e. the server, the I DAM server, the web API, and the corporate user interface comprising the presentation layer are provided in a preceding step. A possible context of this example is the situation of an unauthenticated user 1 (not already logged in) who navigates to the web application, whereby the application redirects the request to the I DAM server 4 to start the process of authentication and showing a login screen, the user 1 entering credentials 5 such as a login and password. The I DAM server 4 then validates the credentials 5 and redirects the request to the web application with a generated valid token 6 as a parameter on the return URL.

From that point onward, the user 1 is considered as authenticated, so he can communicate with the application and perform any action and request to the web APIs 3. Since all the requests to the server must have a valid token 6 on their headers, the web APIs 3, preferably REST web APIs, can perform the validation of the token 6 and verify that every request is coming from an authentic source.

If the signatures, preferably the JSON web signatures relating to the use of a JSON web token, don't match, then it means that the received token 6, preferably a JSON web token, is invalid, which may be an indicator of a potential attack on the application. So, by verifying the token 6, the application adds a layer of trust.

Hereby, preferably, said web API relates to a REST API. Preferably, said presentation layer relates to HTML 5, more preferably to HTML 5 AngularJS. Web pages are preferably encrypted by SSL. Preferably, said token concerns a JSON web token. Hereby, step (a.i) relates to launching the application. Step (a.ii) relates to the requesting of a token 6 using a mobile certificate. Step (a.iii) relates to returing the token 6. Step (a.iv) relates to confirming the authentication with the user 1 and making the application available to the user 1. Step (a.v) relates to an action performed by the user 1. Step (a.vi) relates to requesting a resource with a token 6. Step (a.vii) relates to optionally validating the token 6 and returning the resource requested. Step (a.viii) relates to the displaying of information related to the resource requested over said presentation layer to the user 1.

Claims

A computing system for cash management, the computing system comprising

(b) processing said requirement data by said server to generate an as-is/to- be analysis draft available to a moderator user, said processing based at least partly on said transaction banking historical data;

The computing system according to previous claim 1, characterized in that, said computing system further comprises a corporate user interface and an I DAM server (4) different from said server; in that said corporate user interface comprises a presentation layer (2) configured for HTTPS-based interaction with a user-related device of the corporate user (1); in that said computing system comprises a web API (3) configured for interaction between said presentation layer (2) and a processing part of said computing system; in that said web API (3) is configured for validating a token (6) generated by said I DAM server (4); in that said receiving in step (a) relates to the use of said corporate user interface; and it that said presentation layer

(2) is configured for carrying out the following sub-steps belonging to step (a) and relating to authentication of said user (1) with respect to said computing system:

(a.i) receiving (11) credentials (5), preferably a username and password, from said corporate user (1) via said HTTPS-based interaction with said user-related device;

(a.ii) requesting (12) said token (6) from said I DAM server (4) based on said credentials (5) ;

(a.iii) receiving (13) said token (6) from said I DAM server (4) and storing said token (6) ;

(a.iv) providing (14) said user (1) with access to the computing system;

(a.v) receiving (15) a portion of said requirement data from said corporate user (1) via said HTTPS-based interaction;

(a.vi) sending (16) a message comprising said portion of said requirement data received in step (a.v) and said token (6) stored in step (a.iii) to said web API (3);

(a.vii) after optional validation (170) of said token (6), receiving (17) a response of said web API (3) to said portion of said requirement data; (a.viii) providing said user (1) with said response to said portion of said requirement data.

3. The computing system according to previous claim 2, characterized in that, said web API relates to a REST API; in that said presentation layer relates to HTML 5; and in that said token concerns a JSON web token.

4. The computing system according to claims 1 to 3, characterized in that, said computing system comprises a corporate user interface suitable for display to the corporate user; and in that said receiving in step (a) relates to the use of said corporate user interface, said corporate user interface comprising a questionnaire suitable for sequential completion by said corporate user, said questionnaire comprising a plurality of questions regarding cash management and treasury, said questionnaire comprising at least one interdependency between a first and second question belonging to said plurality of questions.

5. The computing system according to previous claim 4, characterized in that, at least one of said plurality of questions concerns any or any combination of the following: an estimated yearly turnover, an estimated yearly total bank fee, a detailed unit fee, a country-specific overview of transaction types.

6. The computing system according to any of the previous claims 4 to 5, characterized in that, relating to said sequential completion of said questionnaire by said corporate user, a sum of two or more quantities provided by said corporate user in response to said plurality of questions is compared to an estimate also provided by said corporate user in response to said plurality of questions, said estimate relating to said sum of two or more quantities.

7. The computing system according to the previous claim 6, characterized in that, said corporate user interface is configured to generate an alert for said corporate user when said sum of two or more quantities falls outside a range defined by said estimate and a predefined tolerance level.

8. The computing system according to any of the previous claims 4 to 7, characterized in that, said corporate user interface comprises a progress bar indicating a progress of said corporate user in the completion of said questionnaire.

9. The computing system according to any of the previous claims 4 to 8, characterized in that, said computing system comprises a means to facilitate the moderator user in the creation of said questionnaire.

10. The computing system according to any of the previous claims 1 to 9, characterized in that, said computing system comprises a bank user interface suitable for display to the corporate user; and in that, said receiving in step (d) relates to the use of said bank user interface, said bank user interface comprising a rendering of a plurality of requests based at least partially on said RFP, said rendering of said plurality of requests suitable for sequential completion by said bank user.

11. The computing system according to any of the previous claims 1 to 10, characterized in that, said computing system comprises a user account comprising contact details for at least one of the bank user, the moderator user and the corporate user; and in that said computer system is further configured to send a notification to said bank user and/or said moderator user and/or said corporate user via said contact details, whereby said notification is triggered by an agenda item and/or deadline relating to said method to generate said action proposal draft.

12. The computing system according to any of the previous claims 1 to 11, characterized in that, said action proposal draft comprises more than one action proposal alternatives.

13. The computing system according to any of the previous claims 1 to 12, characterized in that, said computing system is further configured for carrying out a method to generate a bank benchmarking report draft, said method comprising the steps of:

(i) retrieving benchmarking information relating to a benchmarking bank user by said server; (ii) processing said benchmarking information to generate said bank benchmarking report draft, said processing based at least partly on said transaction banking historical data; wherein said benchmarking information is retrieved in step (i) through any or any combination of: querying said benchmarking bank user; querying said transaction banking historical data.

14. The computing system according to previous claim 13, characterized in that, said computing system comprises a benchmarking bank user interface suitable for display to the benchmarking bank user; and in that said retrieving in step (i) relates to the use of said benchmarking bank user interface, said benchmarking bank user interface comprising a questionnaire suitable for sequential completion by said benchmarking bank user, said questionnaire comprising a plurality of questions relating to benchmarking.

15. Use of a computing system for cash management according to any of the previous claims 13 and 14 for generating a benchmarking bank report draft.