Digital FNRH for hotels: what changes at the front desk, in the PMS and for guest data

What the Digital FNRH is and when it started

The FNRH (Ficha Nacional de Registro de Hóspedes, Brazil's national guest registration form) is not new. The General Tourism Law (Lei nº 11.771/2008) requires lodging establishments to give the Ministry of Tourism (MTur) a profile and register of the guests they receive (art. 26), and since Lei nº 14.978/2024 the same article says this must respect the rules that protect guests' privacy. What changed in 2026 was the medium: paper forms are no longer accepted, and the data now goes to a federal platform built by Serpro, the government's data processing company.

The change came with MTur Ordinance 41 of 14 November 2025, published on 21 November. Under the original text it would have taken effect 90 days later, on 19 February 2026. The day before, MTur Ordinance 4 extended that to 150 days, and the obligation started on 20 April 2026.

On the day the rule took effect, the Ministry said more than 3,400 lodging establishments were already using the system, out of 19,231 registered in Cadastur (the Ministry's register of tourism businesses), according to Panrotas. So more than 15,000 had not started yet. If your hotel signed up close to the deadline, it's worth checking what was configured in the rush.

The record holds the guest's name and social name, date of birth, nationality, sex, document (CPF or passport), phone, e-mail, address, purpose of trip, means of transport, booking reference, arrival and departure dates and the number of guests, including minors. The FNRH also depends on Cadastur: without an active registration, the hotel can't send anything.

Two ways to send it: integrated PMS or the government portal

The hotel either integrates its PMS with the platform or uses the Ministry of Tourism's portal directly in a browser. Both are free on the government side.

With an integrated PMS, the front desk keeps working in the system it already knows. The integration isn't automatic just because the PMS "has FNRH": each supplier implements the API in its own way, and our comparison of hotel PMS in Brazil shows how much the public documentation on this varies. Before you rely on it, ask the supplier for a demonstration with a real booking, from pre-check-in to check-out.

The API is on version 2. The official documentation, revised during 2026 (version 2.4 is from June), replaced the free-text nationality field with standard country codes and now also asks for the country of residence. Submissions with values outside the standard come back with an error. Ask your supplier which version it uses and how it keeps up with updates. The documentation also provides a staging environment (homologação), where the integration can be tested before it goes live.

How check-in works now

Pre-check-in on the guest's phone

Pre-check-in is optional. The portal generates a QR code for the hotel, which can be printed at reception, and a link to send by e-mail or WhatsApp when the booking is confirmed. Each booking also has its own QR code. The guest fills in their details on their phone, preferably by logging in with gov.br, and arrives at the desk with the record ready. For groups, the Ministry suggests exactly these two options: QR codes in the lobby or a link sent before arrival.

In the Personalizar (customise) section, the hotel can upload its own terms as a PDF, which the guest reads and accepts during pre-check-in, as well as its logo. That's a good place for the hotel's privacy notice (see the LGPD section below).

At the front desk

If the guest doesn't want to use gov.br, or hasn't done pre-check-in, the front desk fills in the record with them. CPF and date of birth are checked in real time against the Federal Revenue (Receita Federal) database, and inconsistent data is rejected on the spot. Foreign guests use their passport, with no CPF or gov.br account, and the system has English and Spanish versions. Minors are linked to an adult's account, and dependants' details are saved for future stays.

One detail catches front desk teams out: once a guest has been added, name, document and date of birth are locked. To fix a typo, you have to remove the guest from the booking and add them again. Put this in the training, so staff don't work around it by creating a second booking.

The hotel is still responsible

The Ministry of Tourism's FAQ is direct about it: legal responsibility for the register lies with the lodging establishment. The hotel has to check the identity of whoever stays and make sure the data sent matches actual occupancy. In practice, that means reporting no-shows and cancellations, not just check-ins. In the system, only a booking with the status "Criada" (created) can be cancelled; after check-in, the route is to record the departure or the no-show. Confirm with your PMS supplier that these events are sent too.

Who controls access: the API key and the users

The Digital FNRH holds personal data on every guest the hotel receives, and access to it runs through two points that often end up without an owner after go-live.

The API key

In the portal's "Chave das API's" (API keys) module, the hotel sees a fixed username and a secret key. The PMS uses this pair to send the data. Whoever holds the key can send and query records on the hotel's behalf, so treat it with the same care as an administrator password:

• Decide who at the hotel can see and generate the key, and write it down.
• Give the key to the supplier over a secure channel, only to be configured in the PMS. No keys in plain e-mail, WhatsApp groups or shared spreadsheets.
• Generate a new key when you change PMS or when someone who had access to it leaves. The API documentation itself recommends rotating credentials regularly.

That last point needs coordination. The "Gerar nova chave" (generate new key) button invalidates the old key immediately, and the manual warns that the action is irreversible. If the supplier doesn't update the PMS straight away, submissions stop. Agree the change with the supplier, at a quiet time, and check the error log afterwards to confirm submissions have resumed.

Portal users

People log in to the portal with a gov.br account or an ICP-Brasil digital certificate. In the Usuários (users) module, the hotel registers staff by CPF with one of two profiles: supervisor, who manages users and settings, and operator, who handles bookings and check-ins. Each user is either active or inactive.

The risk is the same as in any system: someone leaves the hotel and keeps their access. Add the FNRH to your staff leaver checklist, next to the PMS and e-mail, and keep the supervisor profile for a few people. A quarterly review of the user list solves much of the problem.

What to check day to day

With an integrated PMS, it's tempting to forget about the FNRH. But a rejected submission doesn't usually show up on the front desk screen, and the responsibility still sits with the hotel. Three checks cover most problems:

1. The API error log module lists failed submissions, filtered by date, error code and operation (bookings or guests). Someone needs to look at it every day, or get a report from the PMS supplier, and fix what failed.
2. The Fichas (records) module is a read-only register for lookups and audits, with each guest's pre-check-in, check-in and check-out times. Comparing PMS occupancy with the records every so often shows whether something wasn't sent.
3. With an expired Cadastur registration, submissions are blocked. Put the expiry date in the diary of whoever handles admin, with enough notice to renew.

If the internet, the PMS or the government platform goes down, the hotel needs its own procedure. The official documentation we consulted, including the lodging module manual, doesn't say what to do in that case. Our IT contingency plan guide has the questions to ask your PMS supplier and how to handle data written down during the outage.

FNRH and the LGPD: what changes for guest data

The legal basis for sending the FNRH is compliance with a legal obligation (art. 7, II of the LGPD, Brazil's data protection law), so the hotel doesn't need consent to send it. That doesn't remove the rest of the data protection work, and three points need attention.

Sensitive data on the record

Beyond the fields in the ordinance, the lodging module manual and the API documentation include race or ethnicity and disability (with the type of disability). The LGPD classes data on racial or ethnic origin and health data as sensitive personal data (art. 5, II). For both fields, the system offers a "prefer not to say" option.

For the front desk, the guidance is simple: the guest answers. Staff shouldn't guess or fill in these fields themselves, or reuse them in the CRM or marketing profiles. If the hotel needs to know about an accessibility need to prepare the room, that's a different purpose, with a different conversation and a different record.

Transparency and data mapping

The hotel's privacy policy should say that guest data is sent to the Ministry of Tourism because the law requires it, and the data inventory (the record of processing activities) should include the FNRH, the PMS that sends it and the supplier that runs the integration. The PDF terms uploaded in the portal's Personalizar section are one way to put this notice in front of the guest during pre-check-in. Our LGPD guide for hotels covers the legal bases for check-in and the difference between the FNRH and consent for marketing.

Copies you no longer need

According to the Ministry's FAQ, hotels no longer have to keep paper copies for five years, because the records are kept on federal government servers. Plenty of hotels still keep folders of old forms and ID copies "for the FNRH". If that was the only reason, review the retention period and securely destroy what no longer has a purpose. If the ID copy serves another goal, such as defending payment disputes, that use needs a defined legal basis, retention period and access.

When the system was rolled out, social media posts claimed the government would start monitoring guests. The fact-checking site Aos Fatos looked into these claims and found them false. If a guest asks, the answer is short: the form was already mandatory on paper, and what changed is the format.

Enforcement and penalties

Enforcement belongs to the Ministry of Tourism (art. 35 of Lei nº 11.771/2008), which can delegate it to states and municipalities. According to the Ministry's FAQ, it starts with notification. The law, as amended by Lei nº 14.978/2024, provides for:

• A written warning and a fine for not providing the data required by art. 26, which is the legal basis of the FNRH (art. 42).
• A written warning and a fine for providing tourism services without a Ministry registration, or with an expired one (art. 41).
• Fines from R$ 350 to R$ 1 million (art. 36, § 3), graded by the seriousness of the offence, the advantage gained and the offender's economic situation (art. 38). Cooperating with the inspection counts as a mitigating factor (art. 37).

The ordinance is also being challenged in Congress. Legislative Decree Bill 268/2026 (PDL 268/2026), filed on 27 April 2026, proposes to suspend the effects of parts of the ordinance. When we last checked, in October 2026, PDL 268/2026 was awaiting referral. Until it is approved, the ordinance remains in force.

Quick checklist

• Cadastur active, with the expiry date in the diary.
• Sending method decided: an integrated and tested PMS, or the portal with a responsible person named in Cadastur.
• PMS supplier on version 2 of the API, with no-shows and cancellations sent as well.
• Owner of the API key defined, key handed over through a secure channel and replaced when the PMS changes or someone with access leaves.
• Portal users reviewed every quarter, with the FNRH on the leaver checklist.
• Error log checked daily and records compared with PMS occupancy.
• Front desk trained on pre-check-in, locked fields and sensitive fields.
• Privacy policy and data inventory updated, with the hotel's terms uploaded to the portal.
• Paper copies kept "for the FNRH" reviewed and securely destroyed.
• A procedure for when the internet, the PMS or the platform goes down.

Next steps

If your hotel signed up in a hurry in April, the first step is to find out what was set up: who holds the key, who can log in to the portal, whether anyone looks at the error log and what the privacy policy says about the transfer. HotelTI reviews these points as part of our LGPD compliance work or our IT assessment, which takes 2 to 4 weeks. The integration itself is the PMS supplier's job; our role is to define the process, hold the supplier to it and check the result. We don't resell software or have agreements with specific suppliers. Talk to our team.

Sources

• Presidency of the Republic, Lei nº 11.771/2008, General Tourism Law, arts. 26 and 35 to 42, planalto.gov.br
• Ministry of Tourism, Portaria MTur nº 41, establishing the FNRH in digital form (November 2025), gov.br/turismo
• Ministry of Tourism, Hotéis e pousadas têm até 20 de abril para adotar nova Ficha Nacional de Registro de Hóspedes Digital (Portaria MTur nº 4), gov.br/turismo
• Ministry of Tourism, FNRH Digital: perguntas frequentes (FAQ), gov.br/turismo
• Ministry of Tourism and Serpro, Manual de uso: módulo hospedagem (lodging module manual), gov.br/turismo
• Ministry of Tourism and Serpro, FNRH: documento de integração da API (API integration document), version 2.4, gov.br/turismo
• Presidency of the Republic, Lei nº 13.709/2018, General Data Protection Law (LGPD), planalto.gov.br
• Panrotas, Ficha Nacional de Registro de Hóspedes (FNRH) passa a ser obrigatória no Brasil (20 April 2026), panrotas.com.br
• National Congress, PDL 268/2026, congressonacional.leg.br
• Aos Fatos, fact check on claims that the Digital FNRH monitors guests, aosfatos.org