Why IT Blocks New OBT Vendors and How a Data Feed Bypasses Procurement
TL;DR: IT blocks new online booking tools (OBTs) for five structural reasons — SSO/IdP cost, security review load, data migration risk, procurement consolidation mandates, and total cost of change. A data-feed (BYOD) approach sidesteps every one of them because no new booking tool is being introduced; savings and duty-of-care visibility ride on top of the OBT already in production.
At BTN's Chicago Corporate Travel Summit in 2026, the single most common pain point I heard from travel managers was not booking flow, not expense reconciliation, and not traveler experience. It was this: "IT and Procurement won't let me change my OBT."
Drawing from 8+ years building AI-powered corporate travel platforms, the pattern is remarkably consistent. Travel programs identify a better tool — better UX, better content, better negotiated rates, better duty of care — and then they hit a wall that has nothing to do with the tool itself. This article names the structural reasons for that wall and shows why a data-feed approach avoids triggering it.
The Conversation Every Travel Manager Has Tried to Have
The scene is universal. A travel manager runs an RFP, evaluates three or four OBT vendors, picks a winner, and walks the recommendation to IT with a business case attached. Then something predictable happens. Procurement asks whether the incumbent expense platform can "just add booking." Security requests a 40-page vendor questionnaire. Identity management flags SSO configuration cost. Six months later, the RFP is dead — not because the winning vendor was wrong, but because the switching cost inside IT's world exceeds the switching benefit inside the travel program's world.
According to GBTA's 2025 Business Travel Index Outlook, corporate travel spend has now recovered above 2019 levels globally, with US business travel projected to reach $421.4 billion by 2027. Yet 68% of chief procurement officers report vendor-count reduction as a primary KPI (Deloitte 2024 Global CPO Survey). This creates a structural tension: travel programs are asked to deliver savings while procurement is measured on reducing the number of vendors that could deliver them. The result is an environment where new OBT vendors face a 90-120 day security review cycle (ISACA 2024 State of Third-Party Risk), and where identity-management costs alone can add $50k-$120k annually per new SaaS integration for a 5,000-employee company (Gartner 2024 IAM market analysis). Understanding these numbers is the starting point for any conversation with IT.
The Five Real Reasons IT Blocks New OBT Vendors
These are not excuses. Each is a defensible operating principle when viewed from IT's KPIs.
- SSO and identity provider (IdP) cost. Every new SaaS vendor added to Okta, Azure AD, or Ping represents a per-seat licensing tier increase and a SCIM provisioning integration. For a 5,000-employee company, adding one SaaS app to enterprise SSO can add $50k-$120k annually in identity licensing alone, per Gartner's 2024 IAM market analysis. Identity teams are measured on cost per identity, not on travel-program NPS.
- Security review load. A net-new OBT triggers a full third-party risk assessment: SOC 2 Type II review, penetration test results, data-flow diagrams, sub-processor list, DPIA under GDPR Article 35 where applicable, and — increasingly — an AI/ML use disclosure. Enterprise security teams report a median 90-120 day cycle time for full vendor onboarding, per ISACA's 2024 State of Third-Party Risk survey.
- Data migration risk. Moving traveler profiles, payment tokens, approval hierarchies, and negotiated rate loaders from one OBT to another is not a data export/import problem. It is a business-continuity problem. Any migration window where bookings can fail is a P1 incident risk, and IT is measured on P1 incidents.
- Procurement consolidation mandates. Since 2020, most Fortune 1000 procurement organizations have operated under an explicit vendor-consolidation KPI. Deloitte's 2024 Global CPO Survey found 68% of chief procurement officers hold reduction-of-vendor-count as a primary metric. Adding a new travel vendor works directly against that metric, even when the ROI is positive on the travel line.
- Total cost of change. Change management, communications, training, help-desk ticket volume for the first 90 days, and the opportunity cost of the internal analyst who owns the migration typically add 30-50% to the sticker price of the new tool. That number rarely appears in the travel RFP, but IT sees it every time.
Why "Just Push Harder" Doesn't Work
Escalation feels like the answer, but the structural incentives make it a losing game. IT is measured on stability, uptime, and cost per user. Procurement is measured on vendor count reduction and negotiated savings on incumbent contracts. Neither team has a KPI that rewards enabling a travel-program change. Even when the CFO agrees the travel savings are real, the operational cost lands on IT and Procurement — and the savings land in a different cost center. This is a principal-agent problem, not a persuasion problem.
The travel managers who "win" the escalation typically do so at a cost: eighteen months of RFP work, a bruised relationship with IT, and a launch date that slips past the CFO's fiscal-year expectation for realized savings. There is a better path — one that reframes the ask so the structural blockers do not apply.
The Data-Feed Alternative: BYOD
Bring Your Own Data (BYOD) is a structurally different proposition. Instead of introducing a new OBT, a BYOD platform ingests booking data from the OBT already in production — via API, GDS pull, or direct integration — and layers analytics, continuous rate re-shopping, duty of care, and unified reporting on top. Full context on the model is on the Travel Code BYOD hub.
A data-feed (BYOD) approach differs structurally from an OBT switch in five ways. First, no traveler-facing SSO integration is added, because travelers continue booking inside the OBT already in production. Second, security review is scoped to a read-only outbound data feed rather than a booking-critical system-of-record, which places it in a lower-tier review pathway at most enterprises. Third, there is no data migration — booking records flow one direction into the overlay. Fourth, procurement's vendor-count KPI is still impacted, but the total cost of change (training, help-desk, comms) is a small fraction of an OBT switch. Fifth, the traveler population sees zero change, which eliminates change-management overhead. Typical security review for a scoped BYOD deployment: 30-45 days, versus 90-120 days for a net-new OBT (ISACA 2024).
What Still Needs IT Signoff (Being Honest)
BYOD does not eliminate IT review — it narrows it. Three things still require signoff:
- Data Processing Agreement (DPA). The overlay receives PII (traveler names, itineraries, sometimes payment metadata). A GDPR/CCPA-compliant DPA is non-negotiable.
- Outbound data feed. IT needs to approve the API credentials or GDS pull, with scope limited to booking data — not passwords, not full PNRs beyond what is required for duty of care.
- Mobile app for duty of care. If the BYOD platform includes a traveler-facing DoC app, that is a new endpoint. See our companion analysis on BYOD MCP architecture for corporate travel for how modern overlays minimize this footprint, and the Travel Code duty-of-care hub for the operational model.
Realistic security review timeline for a scoped BYOD deployment: 30-45 days at most enterprises, versus the 90-120 days a net-new OBT triggers.
Travel Code Overlay vs Traditional OBT Switch: What Actually Changes
| Dimension | Traditional TMC/OBT Switch | Travel Code BYOD Overlay |
|---|---|---|
| New user login | Yes — full SSO integration | No — travelers keep existing OBT |
| IT security review scope | Full: system-of-record | Scoped: read-only data feed |
| Typical IT review timeline | 90-120 days | 30-45 days |
| Data migration required | Yes — profiles, tokens, hierarchies | No |
| Change management for travelers | Retraining, comms, help-desk spike | None (transparent overlay) |
| Time to realized savings | 12-18 months | 60-90 days |
| Commercial model | Per-transaction / per-user SaaS | RateGuard: 25% of validated savings (no fee if no savings) |
| Duty of care coverage | Vendor-specific | Cross-source, unified |
Three Structural Patterns When Data-Feed Is Proposed
Three structural patterns explain when a travel program reaches for a data-feed overlay instead of an OBT switch. Pattern one — stuck-on-legacy: the program is contractually locked into an incumbent OBT for 18-36 months and needs measurable savings during the lock-in. Pattern two — blocked-RFP-survivor: the program ran a full RFP, selected a winner, and IT or Procurement said no; rather than rerun the exercise in three years, the program layers an overlay that captures 70-80% of the projected value without touching the booking tool. Pattern three — data-team-led: a CFO or head of FP&A requires unified travel-spend visibility across corporate cards, expense platforms, and OBTs; the overlay is procured as an analytics layer first and picks up rate re-shopping and duty-of-care value in year two.
These are typologies, not case studies. Every travel program I've spoken with in 2026 recognizes itself in at least one of them, and often in two.
Where Travel Code Fits
Travel Code is not a TMC and not an OBT. It is a BYOD overlay platform that runs alongside whatever booking and expense stack you already have. Its value comes from three continuous services: RateGuard (post-booking rate re-shopping, priced at 25% of validated savings), unified duty of care across all booking sources, and cross-platform analytics for finance and travel leadership. Because it does not touch the OBT, it does not trigger the five IT blockers described above. For programs whose IT organization has already said no to an OBT switch — see the Travel Code for procurement framing — the overlay path is often the only remaining route to demonstrable savings within the current fiscal year. Explore the model on the BYOD hub.
Checklist for the Conversation with IT
Before you meet with IT, prepare answers to the five questions they will ask. Follow this sequence in the meeting.
- Classify the vendor accurately. Say plainly: this is not a new OBT. It is a read-only analytics and duty-of-care overlay. Vendor classification changes the review pathway.
- Bring the data scope in writing. Booking records at PNR level, corporate card feeds at transaction level, and traveler profiles for DoC. Nothing more. IT will ask; have it ready.
- Answer "why not just expand the existing platform" before it's asked. Most incumbent OBTs cannot re-shop rates continuously and do not offer cross-source DoC. That is the gap the overlay fills.
- Offer a scoped pilot. 90 days, one business unit or region, read-only. IT can revoke API access instantly if anything goes wrong. Pilots close faster than full reviews.
- Show the savings math up front. With RateGuard priced at 25% of validated savings, IT understands there is no fee unless savings are proven. That reframes the ROI conversation for both IT and Procurement.
Frequently Asked Questions
Is Travel Code a TMC?
No. Travel Code is a BYOD overlay platform. It runs alongside your existing TMC and OBT — not instead of them — and adds continuous rate re-shopping (RateGuard, priced at 25% of validated savings), real-time duty of care, and unified analytics on top of the booking and expense tools already in production. The full model is documented on the BYOD hub.
How does the vendor classification change the security review?
A read-only analytics overlay is a materially different risk classification from a booking system-of-record. Most enterprise security teams place read-only integrations in a lower-tier review pathway (30-45 days) than they place net-new booking tools (90-120 days), per ISACA's 2024 State of Third-Party Risk benchmark. Getting the classification right at intake is often the difference between a fast pilot and a stalled RFP.
Can we run a pilot before the full security review?
Yes. A scoped 90-day pilot — one business unit, read-only API access, revocable at any time — is the standard path. It lets IT observe the data flow in production before committing to full deployment, and it lets the travel program produce measurable savings inside the current fiscal year. Pilots also close faster because they carry less institutional risk than a full contract signature.
Does BYOD trigger a new SSO integration?
Not for the traveler population. Travelers continue to book inside the OBT they already use, with the SSO configuration already in place. A small internal admin group (typically 5-20 users) may access the overlay's analytics dashboard, which can be provisioned via SSO or via SCIM depending on your IdP. That is a fundamentally different scope from adding a new booking tool to enterprise SSO.
What data does a BYOD platform actually receive?
Booking records at PNR level (itinerary, traveler name, cost), corporate card transactions where relevant, and traveler profile fields required for duty of care (emergency contact, mobile number). Payment credentials, passwords, and unrelated PII are out of scope. Every field should be documented in the DPA before deployment. Ask any BYOD vendor for a field-level data map; if they cannot produce one, that is a signal.
How does RateGuard's pricing work?
RateGuard is priced at 25% of validated savings. If a booking is re-shopped and the new rate is confirmed as a real savings against the original booking, Travel Code invoices 25% of that delta. If no savings are found, there is no fee. This aligns commercial incentives and simplifies the ROI case for Procurement — there is no floor price, no minimum commit, and the savings are validated before invoicing.
What if our IT team still wants to block a data feed?
Ask them to specify the risk in writing. In practice, a read-only outbound API feed to a SOC 2 Type II certified vendor with a signed DPA is a lower-risk pattern than most SaaS integrations already in your environment. If a specific control is missing, close that control rather than blocking the feed. See the Travel Code duty-of-care hub for how modern overlays handle traveler data end-to-end.
Sources Cited
- GBTA 2025 Business Travel Index Outlook
- Gartner 2024 IAM Market Analysis
- ISACA 2024 State of Third-Party Risk Survey
- Deloitte 2024 Global Chief Procurement Officer Survey
- BTN Chicago Corporate Travel Summit 2026 — primary observations by Egor Karpovich
