How KBS notification works: the web screen or your hotel software

KBS (Kimlik Bildirim Sistemi, the guest identity notification system) is run by two separate authorities: the police and the gendarmerie. A facility's authorized person enters through e-Devlet, creates staff logins, and then either types each guest into the KBS web screen or sends the record from hotel software through a web service.

A guest hands over a passport at 23:40 and the desk has to turn it into a record the state accepts. The hotel has two ways to do that: a browser tab on the reception computer, or the program already open on it. The difference shows up on a busy night, not in a demo. After reading this you will know which authority your facility reports to, how access is set up, how each route works in practice, and what to ask a software provider before you rely on it. For what KBS is and why it exists, see KBS explained: guest identity notification for hotels in Türkiye.

Who runs KBS, and why there are two systems?#

KBS is operated by two separate authorities, and a facility reports to the one whose jurisdiction covers it. The hotel does not choose between them.

The Directorate General of Security (opens in a new tab) put its Kimlik Bildirim Sistemi into service on 18 April 2017 for lodging facilities in police jurisdiction. It holds the details of the people staying and working there, and registered facilities send their records through it instantly (egm.gov.tr, viewed 1 November 2026). The Gendarmerie General Command (opens in a new tab) runs its own system, KBS Tesis 2, and states that facilities can send notifications directly from their hotel management software (jandarma.gov.tr, viewed 1 November 2026).

Which one applies depends on where the facility sits, so confirm it with the local authority before you configure anything. Getting this wrong means logins that never work and records that never arrive. Because the two systems are separate, instructions, screens and passwords are not interchangeable: a guide page for one is not a manual for the other.

Both systems cover two populations: the guests who stay and the people who work there. The login types keep them apart, which is why staff notification is a separate setup from guest notification, covered in KBS staff notification: identity reporting for the people who work at a hotel.

How does a hotel get access to KBS?#

Through the facility's authorized person, who enters KBS via e-Devlet and creates a login for each member of staff who needs one.

The authorized person is the facility's own responsible person. Entry is through e-Devlet, the state portal that identifies a person once and passes that identity to the service. That person can give other staff their own logins, scoped to guests only, staff only, or both. The scope is an operational decision: a night receptionist needs guests, a human resources clerk needs staff, a general manager may need both.

Give each person their own login. A shared login makes the archive useless, because a record can no longer be tied to the person who created it. For the web service route, each authorized user registers the hotel's fixed IP address and a KBS password; the identity number, password and IP are checked together on every call (Gendarmerie KBS Tesis 2 information document, 14 November 2018).

The fixed-IP rule comes from that 2018 document. Check the current page before you build a network plan around it, because rules of this kind change. Keep a written login map and review it when someone leaves: a dormant login with guest scope is a live risk, not paperwork.

Route one: how does the KBS web screen work?#

The receptionist opens the KBS web application in a browser, signs in with their own login and enters each guest by hand. Nothing else is needed but a computer and a connection.

This route has no software dependency, which makes it the natural fallback for every hotel and the main route for a very small property. The cost is double entry: the same identity data is written once into the hotel's own record and once into KBS. Double entry is both the main labour cost and the main source of error.

A T.C. identity number is checked against the population register (MERNİS), so a typing mistake comes back as a rejection rather than sitting quietly in the system. A foreign guest without a foreigner identity number (YKN) is entered with full identity details plus the passport serial number. That is more typing, not less, and it is where queues form.

Check-out is a second transaction with a reason and a date and time. It does not happen because the guest left, and a missed check-out leaves the person recorded as still in the facility. The failure mode is time pressure: at 02:00 with a coach group at the desk, records get written late or one guest gets skipped.

Route two: how does sending from hotel software work?#

The hotel enters the guest once in its own program, and the program sends the record to KBS through the web service module, so there is no second typing.

The 2018 guide describes a web service module so that facilities using hotel automation software can notify instantly once the data is entered in their own program. The hotel's system becomes the place where the record is created. Authentication is the part that breaks in practice: identity number, password and fixed IP address are checked together on every call. If the hotel's connection changes address, calls fail until the registered IP is updated.

A send is only useful if the answer is visible. The receptionist should see accepted or rejected on the same screen as the check-in, not in a log file that nobody opens at midnight. Rejections must carry a reason: a MERNİS mismatch, a missing passport serial number, a field the authority will not accept. A program that shows only "sent" is not doing the job.

Corrections and check-outs need the same treatment. A delete-and-re-enter correction made in the hotel program has to reach KBS, not only the local database. Ask whether failed sends are queued and retried, and whether the queue is visible to the desk. An invisible queue is a silent backlog.

When should a guest be entered, and how are check-outs, groups and corrections handled?#

The official guide says a guest should under normal conditions be entered at the moment of check-in. Check-out is recorded separately, with a reason and a date and time.

On timing, the guide's wording is "at the moment of check-in" under normal conditions. No deadline counted in hours is published, so do not build a routine around a number you cannot cite. On identity, a T.C. number is checked against MERNİS; a foreign guest without a YKN is entered with full identity details and the passport serial number.

Corrections work like this: a field that cannot be updated is corrected by deleting and re-entering the record. Plan for it, and make sure the person who made the error can fix it and that the fix is visible in your own log. Check-out is recorded with a reason and a date and time, and this is the step hotels forget, because the guest's departure feels like the end of the transaction. It is not.

Groups are the good news. Confirmed reservations such as tour groups can be notified in advance, which is the single most useful line in the guide for any hotel that receives coaches. The authorized person can use the notification archive to check that entries were made correctly and on time, so make that a weekly task with a named owner. For children and companions, no specific official rule was verified beyond the law's general wording, so confirm your own case with the authority rather than guessing. The desk-level routine is covered in KBS at check-in: a front desk checklist for guest identity.

What should a hotel do when the KBS connection fails?#

Run a written fallback that keeps the guest record complete and gets it into KBS as soon as the connection returns, with a named person responsible on each shift.

Know the failure modes before they happen: internet down, the registered IP address changed, an expired password, the authority's system unavailable, or a web service rejecting a record without a clear reason. The fallback itself is simple: capture the full identity data at check-in on paper or in the hotel system, mark the record as pending, and enter it through the web screen when the line returns.

Name one person per shift who owns the pending list, and a second person who checks it at the end of the shift. Two names, not a department. Keep a simple log: time of failure, records affected, time resolved, who resolved it. It is what you show when someone asks whether the notification was made.

Test the web screen login once a month. A fallback nobody has opened in a year is a plan on paper. When the failure is on the authority's side, report it and keep the reference; that record protects the hotel later.

What should you ask a hotel software provider about KBS?#

Ask for the mechanism, not the feature: who authenticates, what the receptionist sees when a record is rejected, and what happens when the line drops mid-check-in.

A provider that answers these questions with a screenshot of a settings page has not answered them. Ask to see the check-in screen and the rejection message. Ask which of the two systems the integration was tested against, and whether it is live at your property or waiting for credentials. Ask what the program does with the fixed IP address, and who updates it when your connection changes. Ask whether the notification archive can be filtered and exported, because that is how you will answer questions months later. These questions belong in the wider evaluation covered in How to choose a hotel PMS in Türkiye: questions to ask vendors.

That last question is fair to ask of any vendor, including us. AI Otel's compliance layer is built: KBS guest notifications are prepared and sent from the check-in flow. The integration is developed and tested with fixture data; going live requires the authority and integrator credentials.

What to do next#

Take the checklist to your current provider, or to the two or three you are evaluating, and ask for the answer on a screen rather than in a brochure. Then write the fallback routine down and test it once. The article comes down to one rule that holds whichever authority and whichever route applies to you: the record must be complete, made at the right moment, and checkable in the archive afterwards. If you want to see how the check-in flow and the KBS notification sit together in one system, you can request a briefing.