Protection against illegitimate booking requests

[Dimitris Argirakis]

Good evening,

After reading the article: https://blog.windingtree.com/protection-against-illegitimate-booking-requests-d34a54a5fe8b, I have some suggestions.

Of course everyone, if we assume the platform goes online tomorrow, could open up (example) a Hotel and start getting reservations. This will be a fraud. I think we understand this. BUT... I am 100% convinced that this can be resolved by involving each hotels PMS system in the booking/reservation requst procedures. How?

Scenario: Lets imagine all hotels around the world have a PMS system in place. The PMS can act as a security/controlling interface in the process by proiving following service:

a) when a request is send to the hotel, the PMS can provide information about any available History transaction(s) by the person/agency/company requesting a reservation. If the PMS has a history log about this Person/Agency/company, then the request is automaticaly secure. The "evidence" proof the PMS will provide includes all details about the source the request is coming from.

b) The PMS is connected (only for this task) with any other PMS of the hotels around the area (for chain hotels this will be much easier). If Hotel A receives the request for the first time "red or orange", but the PMS from hotel B confirms, that the source is "Green", then the PMS of hotel A automatically turns this "new" request into "green".

c) If a "fake" request copies a "non fake" source to produce a reservation request, the PMS places this as "orange". The hotel, as per current procedures, demands a guarantee from source to secure the request/reservation. This can be also done by a smart contract.

d) Alternatively, the same "proof of work" can be done by the CRM of the hotel.

In my opinion, the PMS needs to play a role. A hotel with 100 rooms, a 10 year operation and 65% occupancy has a data of 237'250 reservations (100 x 365 x 65%). If the average repeated guests make 25% of these resrvations, it means the PMS holds 178'187 unique Person/agency/company data Profiles. this way, on the day the hotel joines the Blockchain Platform, there is already a data bank which will ensure the legitability of all previous transactions.

Imagine the Platform translates a(n) Guest/Agency/Company as "Red", meaning high risk because the Platform has no history of any previous transactions. Hotel A though has a long business cooperation with the client(s). What happens then? Will these be rejected? Will the reservation agent(s) need to refer to the PMS to "double check" if there is a history of this client?

Again. I am 100% convinced the PMS MUST have a role. And from my knowledge in the Hotel Business, it will be a vital one.

regards

Dimitris

[Jakub Vysoky]

Dimitris, I agree with you. A history of valid transaction from a PMS system can totally act as a proof of validity. We have this in mind. With the only difference, that we want the Person/Agency/Company to have this responsibility of holding their history of transactions (of course it can be another service on behalf of them) and sending them if needed to prove their trust.

Not sure if it is some communication between PMSs, how to avoid some malicious PMS screwing data about customers from others.

But let's keep brainstorming! Thank you!

--
You received this message because you are subscribed to the Google Groups "Winding Tree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to windingtree...@googlegroups.com.
To post to this group, send email to windi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/2b634dc7-2737-4339-8bfe-e4e2491ae245%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephen Burke]

As long as the PMS transaction is not in the critical path of the shopping and booking process, it may make sense.  

Regards,

Stephen

+420 776 491 795

Sent from my iPhone, please excuse the typos

To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/CAEO8NYysZs7PqXCJun2we4B8YHhr3gSonqt5jH6D9CEgkb4g%3Dw%40mail.gmail.com.

[Jakub Vysoky]

Not "screwing" but "scraping" - autocorrect :)))

[Dimitris Argirakis]

Dear Jakub thank you. The malicious PMS screwing data problem is well known and where there is a "clever" CRS in place the problem does not exist. Of course its always the responsibility of the client to ensure holding their history transactions (can this not be faked?), but a kick start with a history data bank of hundreds of "green" clients, is always a good start. Thank you for your support and feedback. Dimitris

[Jakub Vysoky]

> history transactions (can this not be faked?)

we are using cryptographic signatures for booking request/responses => there is no room for faking! that is the beauty! 

To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/CAJ7BYJPGxb3rVcmaJ8gHgXMtYX8%3Dqs6MCqwuRuFz6XE4Yp6hxw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Jakub Vysoky

http://windingtree.com/

[Dimitris Argirakis]

Dear Group. On this subject I had an email exchange with Jakub but unfortunately I did not "reply all" only to Jakub. Below are all emails. It will be great to hear what you all guys think:

Dear Jakub, I am sorry for not making my point very clear. One of the major and in the same time common mistake made by the front office when the data of a Guests requiring a reservation or is checking in, is that of misspelling, when entering the guests data in the PMS when these MUST be added manually. Manually meaning direct booking..really what we all (hotels) want. All date from guests who book online either via an OTA, GDS or via our own Website, are automatically entered correctly to the PMS with our two way Interface. The average fair share depending on the country and city is: 40% Online bookings via OTA, 40% direct (where mistakes happen) and the rest are GDS or high street travel agencies.

Now with the example I gave above with a hotel of 100 rooms (65% occupancy), the direct manually added booking in the PMS is around 71'000. Now lets take this axample:

Mr John Smith books directly and sends an email providing also his address/invoice address. Mr Smith, lives in Penthull Street 98, Stoke on Trend, ST1 1EE, UK. If, and believe me it happens all the time, the front office enters the address with a mistake either by missing a letter or adding a wrong postal code, Mr Smith, the next time he decides to use the Blockchain Platform, he will show up as a new customer with no history in the hotel. The CRS when installed and used by hotel(s), the algorith the system uses, automatically corrects the mistake and pass the data the PMS.

Unfortanately, and because the majority of the hotels worldwide are indipendant hotels, only aroung 15% of them have a CRM installed.

This is what I mean. Imagine booking a room or send a request to a hotel you have been before, inside the Platform and not the common way.. The system will not recognise you as a return Guest but will pressent you as a new one. This problem, although it does not sound important, is one of the top 5 negative experiences Guests have in a hotel when checking in. Another problem, will be if a guest is a frequent visitor at the hotel, with a special rate, free upgrade etc etc, and the hotel has created a smart contract with him/her. What will happen then? The guest will be dissapointed, and will raise quality service questons. Hotels do not want that to happen. This is why I (and I apologize for being stubborn on this one), am 100% sure the PMS needs to play a control role. Noone owns the guest data in Blockchain....but as the English say: "You never get a second chance for the first impression". So the day our vision is lunched, I do not want these guests to be left with a bitter taste when using the platform for the first time,

Please also note, OTAs do not check if your name is Rafel or Raphael... We, though, do care a lot.

PS: Ideas as an example, (https://ideas.com/) is a revenue software which depending of the decision level you want it to be (many hotels do this), will automatically reject a reservation request, or prioritise a "green" booking instead of an "orange" or "red". if the revenue system "adopts" itself to the new blockchain era, (eventually this will happen as yield and revenue management will still play a vital role to the hotels), it will cause prolems.

Sorry this email was long.

I wish you a happy evening.

Warm regards

Dimitris

On Mon, 8 Apr 2019 at 17:47, Jakub Vysoky <ja...@windingtree.com> wrote:

> history transactions (can this not be faked?)

we are using cryptographic signatures for booking request/responses => there is no room for faking! that is the beauty! 

On Sat, Apr 6, 2019 at 2:37 PM Dimitris Argirakis <dimitris....@gmail.com> wrote:

Dear Jakub thank you. The malicious PMS screwing data problem is well known and where there is a "clever" CRS in place the problem does not exist. Of course its always the responsibility of the client to ensure holding their history transactions (can this not be faked?), but a kick start with a history data bank of hundreds of "green" clients, is always a good start. Thank you for your support and feedback. Dimitris

Jakub Vysoky <ja...@windingtree.com> schrieb am Sa., 6. Apr. 2019, 13:04:

Not "screwing" but "scraping" - autocorrect :)))

On Sat, Apr 6, 2019, 13:26 Jakub Vysoky <ja...@windingtree.com> wrote:

Dimitris, I agree with you. A history of valid transaction from a PMS system can totally act as a proof of validity. We have this in mind. With the only difference, that we want the Person/Agency/Company to have this responsibility of holding their history of transactions (of course it can be another service on behalf of them) and sending them if needed to prove their trust.

Not sure if it is some communication between PMSs, how to avoid some malicious PMS screwing data about customers from others.

But let's keep brainstorming! Thank you!

On Fri, Apr 5, 2019, 22:30 Dimitris Argirakis <dimitris....@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Winding Tree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to windingtree...@googlegroups.com.
To post to this group, send email to windi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/2b634dc7-2737-4339-8bfe-e4e2491ae245%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Winding Tree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to windingtree...@googlegroups.com.
To post to this group, send email to windi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/CAJ7BYJPGxb3rVcmaJ8gHgXMtYX8%3Dqs6MCqwuRuFz6XE4Yp6hxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Jakub Vysoky

http://windingtree.com/

Jakub Vysoky

21:29 (4 minutes ago)

to me, Jakub

[Jirka Chadima]

I wrote a followup on the original post: https://blog.windingtree.com/building-trust-on-a-trustless-blockchain-ba71872f8541

Our design (hopefully) allows to create some sort of proof based on PMS's history with other actors. However, it itself is quite a big task, so we are not tackling it at the moment, eventhough it popped up in our discussions about the validity/spam protection/trustworthiness topic. There are probably some missing pieces to do this safely (encrypting personal data etc.), but it is something we know about. If anybody comes with a reasonabl sound design of this, we will be more than happy to elaborate on it.