Duty of Care Without Changing Your OBT: A Data-Feed Approach to Coverage on Every Booking
TL;DR: Duty of Care platforms coupled to an online booking tool (OBT) only cover bookings made through that OBT. Every direct-supplier reservation, consumer-site booking, or corporate-card purchase made outside the OBT is structurally invisible. A data-feed approach — combining a supplier API, an email-forward inbox, and a mobile self-report — closes the gap on every booking source without requiring a TMC or OBT migration. This guide walks through the architecture, the implementation steps, and the checklist for complete coverage.
The structural gap most travel managers don't realize they have
Consider a hypothetical procurement leader at a mid-market manufacturer. The company has a tier-one OBT, a global TMC contract, and a Duty of Care dashboard that lights up green on a Monday morning. Two of her engineers are flying that week — one to Stuttgart, one to São Paulo. The dashboard shows both itineraries. What it does not show is the third engineer, who booked a last-minute flight on a consumer OTA because the OBT did not return availability on the route, and the fourth, who extended a customer trip into a weekend and rebooked the hotel on a personal loyalty account. Two travelers are visible. Two are not. The dashboard is not lying — it is reporting honestly on the data it has. The data it does not have is the problem.
This is the structural gap inside most corporate Duty of Care programs in 2026. It is not a question of dashboard quality, alert latency, or sourcing rigor. It is a question of whose bookings count — and the honest answer, in an OBT-coupled architecture, is "only the ones the OBT touched."
Why OBT-coupled Duty of Care creates this gap by design
OBT-coupled Duty of Care works because the OBT is the source of record for the booking. Every itinerary that flows through the booking tool becomes an itinerary the DoC platform can see. That is also why it fails: anything that does not flow through the OBT is invisible to the same platform. The architectural assumption — "all corporate travel must be booked through the corporate booking channel" — has never been fully true, and program leakage rates that travel managers privately quote at industry events suggest it is getting less true, not more, as travelers grow comfortable with consumer-grade interfaces.
Drawing from time spent with corporate travel managers at the Business Travel News Group Travel Manager Forum in Chicago, April 2026, the pattern was consistent across roughly forty conversations: every program had leakage, no program had measured it precisely, and almost every program leader had stopped believing the official adoption number on their own slide. The OBT does what it is designed to do. It cannot see what was never booked through it.
What "complete" Duty of Care actually requires
Complete Duty of Care, in operational terms, is the ability to (1) locate every traveler the organization is responsible for, (2) communicate with each one within minutes, (3) assess exposure against a current risk picture, (4) respond with extraction, rebooking, or care, and (5) document each of the above for legal and audit purposes. The five-item checklist below is the operational standard the rest of this article maps to:
- Locate — Real-time itinerary visibility on every booking, regardless of source (OBT, TMC, direct supplier, consumer site, corporate card, personal card reimbursed later).
- Communicate — Two-way messaging that reaches the traveler on a channel they actually read (mobile push, SMS, app inbox), with delivery receipts.
- Assess — A risk picture refreshed continuously and matched against current traveler location plus next-72-hour itinerary, not just origin and destination.
- Respond — Pre-defined escalation paths with the people, vendors, and authority required to rebook, extract, or fund care without waiting on internal approvals.
- Document — A defensible audit trail showing what the organization knew, when it knew it, and what action it took — sufficient to satisfy the diligence expectations described in ISO 31030:2021, the international standard for travel risk management published by the International Organization for Standardization in September 2021.
A program that cannot complete all five items, on every booking, has a gap. The most common gap in 2026 is item one. The data-feed approach exists to close it.
The data-feed approach: Duty of Care on every booking, regardless of source
The data-feed approach inverts the OBT-coupled model. Instead of asking "how do we force every booking through the platform that owns Duty of Care?" it asks "how do we get every booking into the Duty of Care record, regardless of where it was made?" That question has three answers running in parallel, which together form the Bring Your Own Data architecture:
- Supplier / TMC / GDS API feed — for structured itineraries from airline, hotel, rail, and TMC partners. Real-time, machine-readable, normalized at ingestion.
- Email-forward inbox — every traveler gets a forwarding address. Any confirmation, from any source — consumer OTA, direct supplier, corporate or personal — gets parsed into the itinerary record within seconds. This is the path that captures the leakage the OBT cannot see.
- Mobile self-report — a thirty-second flow inside the traveler app for cash-paid, last-minute, or paper-confirmation trips, including ground transport and informal stays. This is the path that captures the leakage the email-forward cannot see either.
The three feeds collapse into one traveler-itinerary object. Risk alerts, location tracking, two-way messaging, and incident response all run against the unified record. The OBT keeps doing what an OBT does well — policy, approvals, self-service — and the Duty of Care layer stops depending on the OBT to be the source of truth for traveler location.
A first-person observation from BTN Chicago, April 2026
At the BTN Group Travel Manager Forum in Chicago this past April, I sat in on a roundtable where the moderator asked a room of around forty travel managers a single question: "What percentage of your trips do you believe are actually booked through your OBT?" The official number on most programs' annual reviews was somewhere between 75 and 90 percent. The number the room volunteered, off the record, was closer to 55 to 70 percent. Nobody contested it. One travel manager — large pharma — said quietly that her real adoption was probably under 50 percent once she counted bleisure extensions and last-minute rebookings on personal cards. That is a primary observation, not a third-party statistic, and it is the single most useful data point I have seen this year for sizing the Duty of Care gap in real programs.
How to implement Duty of Care without migrating off your OBT
The implementation pattern below works for organizations that want to keep their current OBT and TMC contracts intact while closing the coverage gap. It runs in roughly thirty days from kickoff to first live alerts, depending on how many supplier APIs are in scope.
- Inventory every booking surface employees actually use. Map the OBT, the TMC, direct supplier sites, consumer OTAs, corporate cards, and personal cards reimbursed later. Pull a sample of expense reports from the last quarter and tag every line that resulted in a trip. The gap you cannot see is the gap you cannot cover.
- Stand up three ingestion paths in parallel. Connect a supplier/GDS/TMC API feed for structured bookings; provision an email-forward inbox per traveler and parse confirmations from any source; deploy a mobile self-report flow for cash-paid, last-minute, or non-electronic itineraries. The three paths are additive, not alternative.
- Normalize the data into a single itinerary record. Parsed records must collapse into one traveler-itinerary object per trip, regardless of where the booking originated, so risk alerts and traveler tracking run against one schema rather than three.
- Layer alerts and communication on the unified feed. Trigger location-based risk alerts, two-way messaging, check-in workflows, and incident response against the unified record. The OBT does not need to know any of this happened. The Duty of Care layer does.
This is the operational core of the BYOD methodology: separate the booking channel from the visibility channel, so the visibility channel can be complete.
Comparison: three approaches to Duty of Care coverage
| Capability | OBT-coupled DoC | Manual reconciliation | Data-feed DoC (BYOD) |
|---|---|---|---|
| Coverage of OBT bookings | Complete | Complete (but redundant) | Complete |
| Coverage of direct-supplier bookings | None | Partial — depends on expense reporting lag | Complete via email-forward + API |
| Coverage of consumer-site bookings | None | Partial — depends on traveler discipline | Complete via email-forward |
| Coverage of cash / last-minute trips | None | Trailing only — surfaces after the trip | Complete via mobile self-report |
| Time-to-locate during an incident | Minutes (for visible bookings) | Hours to days | Minutes across all sources |
| Requires OBT or TMC migration | Often yes | No | No |
| Defensibility under ISO 31030:2021 | Partial — only for in-channel bookings | Weak — trailing visibility | Strong — single audit trail across sources |
The honest read of this table is that OBT-coupled Duty of Care is not wrong — it is incomplete. The data-feed approach is the layer that makes it complete without forcing the rest of the program to change underneath.
Where this fits in a broader travel risk program
A Duty of Care layer does not replace travel insurance, an emergency assistance retainer, a defined evacuation provider, or the underlying corporate travel policy. It feeds them. For programs reviewing the wider risk stack, our guide to Duty of Care in corporate travel covers the policy and governance layer, the business travel insurance guide covers underwriting and claims, and the bleisure policy guide covers the personal-extension scenarios that produce most of the off-OBT leakage. For travel managers whose IT or InfoSec function has historically vetoed new OBT plug-ins, the explainer on why IT blocks new OBT vendors describes the specific objections a data-feed model avoids by sitting beside the OBT rather than inside it.
The pattern Travel Code has built around — a Bring Your Own Data ingestion layer that does not require you to change your OBT, your TMC, or your expense system — exists because every program we have talked to in 2026 has the same gap, and the gap is structural, not operational.
Frequently Asked Questions
Can a data-feed Duty of Care layer work with my current OBT?
Yes. A data-feed approach sits beside the OBT and ingests from it, rather than replacing it. The OBT continues to handle policy enforcement, pre-trip approvals, and self-service booking; the Duty of Care layer adds coverage for every booking the OBT does not see — direct-supplier, consumer OTA, personal card, last-minute. No migration, no contract renegotiation, no change to the booking experience travelers already know.
How does this approach handle bleisure trips booked on personal accounts?
Mobile self-report and email-forward capture personal-account bookings without forcing them into the corporate OBT. The traveler keeps the loyalty point and the personal booking flow; the employer keeps Duty of Care visibility for the dates the traveler is on company business. This is the path most bleisure policies need but most OBT-coupled platforms cannot serve. See our bleisure travel policy guide for the policy side.
How fast do risk alerts reach the traveler?
Alert speed depends on the ingestion path. API-fed bookings appear in the itinerary record in real time. Email-forwarded confirmations are parsed within seconds of arriving in the inbox. Mobile self-reports are instant on submission. Outbound alerts to the traveler then run over push notification, SMS, and app inbox in parallel, with delivery receipts logged for audit.
What if our IT or InfoSec team blocks new vendors from touching the OBT?
The data-feed approach does not require integration into the OBT itself — only read access to confirmation emails or a supplier API. That removes most of the change-control and security-review objections IT typically raises against new OBT plug-ins, because there is no plug-in. The IT blockers explainer walks through the specific objections this architecture sidesteps.
Does ISO 31030 require any specific technology stack?
No. ISO 31030:2021, the international standard for travel risk management published by the International Organization for Standardization, is technology-agnostic. It specifies that the organization must identify travelers, communicate risk, respond to incidents, and document its diligence — not which platform delivers those capabilities. A data-feed Duty of Care layer satisfies the standard's location and communication requirements on a wider set of bookings than an OBT-coupled platform can, because it sees more of the trips.
What does this cost compared to ripping out the OBT?
The economics favor adding a data-feed layer rather than replacing the OBT, in most programs, because OBT migration carries hard costs in implementation, change management, and traveler retraining that a parallel data layer avoids entirely. Our corporate travel booking tool comparison covers the OBT replacement scenario for programs that do want to migrate, and the TMC RFP guide covers the contract-renegotiation path.
Closing observation
Duty of Care platforms are usually evaluated on the dashboard, the alerts, and the response workflow. The more useful evaluation is on the denominator: of every trip the organization will be responsible for this quarter, how many will the platform actually see? When the denominator is the OBT, the answer is whatever the OBT touched. When the denominator is the traveler — captured through whatever combination of API, email-forward, and self-report it takes — the answer is closer to complete. That shift, from booking-channel-as-source-of-truth to traveler-as-source-of-truth, is what a data-feed approach delivers, and it is the operational pattern that closes the gap most corporate programs are quietly carrying into 2026.
Sources cited: ISO 31030:2021 Travel Risk Management — Guidance for Organizations, International Organization for Standardization, published September 2021. First-person observations from the BTN Group Travel Manager Forum, Chicago, April 2026.
