# RankShield Integration Path: Gilbarco Passport POS | RankShield Financial > How RankShield Financial reads fraud signals from a Gilbarco Passport site — journal feeds and processor authorization detail, observe-first, with no pump or POS hardware changes. > > Source: https://rankshieldfinancial.com/integrations/gilbarco-passport/ · RankShield Financial (verifiable pre-settlement payment security) Integration path · Fuel & convenience systems # Fraud verdicts for Gilbarco Passport sites without touching the POS or the pumps. RankShield integrates beside a Gilbarco Passport installation, not inside it: it reads the transaction journal the back office already exports and the authorization detail your processor already reports, scores both in real time, and seals every verdict to the RankShield Network — while Passport, the forecourt, and the payment path keep running exactly as they do today. Request a pilot See the industry page feeds-only observe-first fail-safe: payments flow The integration position Payment path untouched — never proxied Store hardware nothing installed Data consumed journal + processor reporting Default state observe · fail-safe serve 01 // the stack Where the data already lives ## What a Passport site already produces Passport is the point of sale and the brain of the forecourt: it drives the dispenser card readers, runs the registers inside, and hands every card authorization to the payment network. Along the way it produces the two data streams fraud detection needs. First, a transaction-level journal — sales, refunds, voids, no-sales, cashier and register identifiers — exposed through the back-office interface in the industry-standard NAXML format that back-office systems consume. Second, the authorization records themselves, which your processor sees for every pump and register transaction, including the terminal that originated it and how the card was read. The position ## Why we integrate beside it, not inside it A fuel POS is certified, hardened, and busy — the last place to bolt on new software. RankShield therefore takes the read-only position: journal feeds from the back office, authorization detail from the processor side. That is enough to run velocity scoring per dispenser terminal, fallback-rate divergence per pump, and refund-chain analysis per register — with zero changes to price book, forecourt configuration, or the payment path. 02 // tap points Where RankShield reads ## Three tap points, zero store changes Each feed already exists at the site. The integration directs it to one additional recipient you control. ### Back-office journal feed NAXML transaction detail The journal export Passport already provides to back-office systems carries register-level events — refunds, voids, no-receipt returns, cashier and shift identifiers. This powers refund-chain and register-level rules. ### Processor authorization detail per-terminal auth stream Authorization records from your acquirer carry terminal ID, amount, timestamp, and card-entry mode. This is where card-testing velocity and chip-fallback divergence per pump become visible. ### Fleet back office, if present one connection, every store If stores roll up to a fleet back-office platform, one integration there covers every site’s journal at once — usually the fastest Phase-1 path for a chain. 03 // under the hood Under the hood ## Reading a Passport site through the export interface it already runs Passport is not a black box: it ships a named, configurable file-export gateway, and that gateway is the door RankShield reads through. **On this stack specifically:** Card-entry-mode signals (chip versus fallback swipe) come from the processor-side authorization data, not the POS journal — so the skimmer-signature rule needs the processor feed connected, not just the back office. ### The XML Gateway is the door, not a new one Passport carries an XML Gateway that publishes site data on a configurable file-polling cycle, with the interface format set to a NACS XML convention and an output directory the operator controls. Chains already point that gateway at accounting and fuel-reconciliation systems. RankShield becomes one more authorized destination for the same export, reading the sales, refund, void, and shift records Passport writes there. Nothing on the register or the back-office server is re-engineered: the export exists, the polling cycle exists, and the operator simply designates an additional recipient. That is what keeps the first phase a configuration task on data Passport already publishes, rather than any change to how the site rings a sale or authorizes at the pump. ### Where the card is actually read: the forecourt controller On a Passport forecourt the dispenser card readers do not talk to the register directly. They sit behind a forecourt controller, such as the DOMS PSS 5000, that drives the pumps and passes authorizations upward. That physical layer is exactly where a shimmer lives, and where a chip read is forced to fail over to magstripe. RankShield does not touch that controller or the readers it manages. It reads the authorization detail those pumps generate from the processor side, so a fallback-rate break on one dispenser position becomes visible as data without any presence on the forecourt hardware. The forecourt stays a certified, sealed system; the signal it leaks is read from beside it. ### What the gateway export cannot tell you, and what completes it Two things the XML Gateway export cannot carry on its own: whether a card was dipped or swiped, and which authorizations the processor declined. Passport writes completed sales and register events there, not the response codes behind them. So the skimmer and card-testing rules on a Passport site are only as good as the processor feed paired to them: the gateway supplies the register and shift half, the authorization detail supplies the pump-and-card half, and RankShield joins the two per dispenser position. A deployment that connects only the XML Gateway gets refund-chain and register coverage; the physical-skimmer signature waits on the authorization side being connected too. The page states which half each rule depends on. 04 // what it surfaces What it surfaces ## The fraud these feeds make visible Each rule family maps to a documented, measured loss pattern in fuel and convenience retail. $428M in potential losses the U.S. Secret Service estimated it prevented in a 2025 skimming crackdown — 411 devices removed across 9,000+ businesses, fuel pumps a primary target 5 31% of traffic to food and grocery sites is bad bots — the enumeration pressure that hits online and unattended card endpoints (Imperva/Thales 2025 industry measurement) 6 At a Passport site the highest-value fraud hides at the unattended dispenser overnight: a stolen-card batch validated in small authorizations at one pump, or a shimmer forcing that pump to fall back to magstripe while its neighbors read chips normally. Neither shows in the XML Gateway export, which records completed sales, not declines or card-entry mode. The processor authorization feed is what makes both visible, scored against that specific dispenser position’s own baseline rather than a storewide average. 05 // check your readiness An honest two-minute read ## Is your site data ready for this? Each question maps to a feed or control this integration depends on. The tally runs in your browser — nothing is transmitted. - 01 Does your back office already aggregate a NAXML journal across your sites? - 02 Can your processor deliver authorization detail including declines and card-entry mode? - 03 Today, can you see declined authorizations per pump — not just completed sales? - 04 Would a fallback-rate spike on one pump trigger anything automatically? - 05 Are refunds and voids scored per register and per employee each shift? Answer all 5 to see where you stand · 0/5 06 // rollout Observe first, enforce when earned ## The rollout that cannot break your stores The default state at every phase is no-change: nothing is blocked until observe mode has proven accuracy on your own store traffic. WEEK 1 ### Connect the data, touch nothing RankShield consumes feeds this stack already produces — transaction journals, authorization detail, settlement files. Nothing is installed on registers, pumps, or terminals, and no payment path is modified. WEEKS 2–4 ### Observe mode builds the baseline The rail scores live traffic and shows what it would have flagged — per terminal, per register, per store — so accuracy is proven on your own data before any transaction is touched. If RankShield is ever unavailable, the default is fail-safe: payments flow. GO-LIVE ### Enforce where the numbers earn it Holds and blocks are enabled surface by surface, and every verdict is sealed to the RankShield Network with a receipt you can verify independently — so a declined payment always has a checkable answer to “why?” 07 // what we verify The rule families ## What the rail watches on this stack - Authorization velocity per dispenser terminal against that pump’s own baseline - Chip-read fallback rate per pump versus its neighbors — the skimmer signature - Refund and void chains per register, per shift, per destination card - A sealed, independently verifiable receipt for every verdict Independence, stated plainly ## An integration path, not a partnership claim Gilbarco Passport is a product of Gilbarco Veeder-Root. RankShield Financial is an independent platform and is not affiliated with, certified by, or endorsed by Gilbarco Veeder-Root. This page describes RankShield’s supported integration architecture for merchants who run Gilbarco Passport: it consumes data feeds the merchant already owns and directs — transaction journals and processor reporting — and never modifies the named system or its payment path. We hold every page on this site to the same standard as our verdicts: [claims you can check](https://rankshieldfinancial.com/transparency/). Primary sources ## References Standards are cited to the bodies that maintain them; fraud statistics to government and association primaries. Measurements from industry vendors are labeled as such. - [Conexxus — NAXML data standards for convenience and fuel retail](https://www.conexxus.org/standards) - [ISO — ISO 8583 financial-transaction card messaging standard](https://www.iso.org/standard/31628.html) - [EMVCo — EMV chip specifications (governing body)](https://www.emvco.com/) - [PCI Security Standards Council — PCI DSS](https://www.pcisecuritystandards.org/) - [U.S. Secret Service — Nationwide Crackdown on Card Skimming and Fraud](https://www.secretservice.gov/newsroom/behind-the-shades/2026/01/inside-our-nationwide-crackdown-card-skimming-and-fraud) - [Imperva / Thales — 2025 Bad Bot Report (industry measurement)](https://www.imperva.com/resources/wp-content/uploads/sites/6/reports/2025-Bad-Bot-Report.pdf) - [Visa — Anti-Enumeration and Account Testing Best Practices](https://usa.visa.com/support/small-business/security-compliance.html) - [ACFE — Occupational Fraud 2024: A Report to the Nations](https://www.acfe.com/-/media/files/acfe/pdfs/rttn/2024/2024-report-to-the-nations.pdf) FAQ ## Integrating beside Gilbarco Passport, answered Every question buyers ask before they trust a payment-security platform, answered directly. JAMIE KLONCZ · RANKSHIELD FINANCIAL ONLINE Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it. REQUEST ACCESS → The rest of the stack ## Other integration paths Verifone Commander NCR Voyix PDI Enterprise Fiserv Worldpay Chase Payment Solutions All integrations See the full fuel & convenience picture Verify, then settle ## Start with your own data, not our promises. Phase 1 is a findings report on sixty to ninety days of your existing journal and authorization history: what the rules would have caught, store by store, before anything touches production. Request a pilot How it works ## Frequently asked questions ### Does this require installing anything on Passport or the pumps? No. The integration position is deliberately beside the stack, not inside it. RankShield consumes the transaction journal the Passport back-office interface already exports and the authorization detail your processor already reports for every terminal. Nothing is installed on the POS, the site controller, or the dispenser card readers, no certification of the payment path is disturbed, and the forecourt configuration is untouched. That is what makes the first phase a data exercise rather than a store-disruption project: connect two feeds that already exist, and the scoring runs on our side. ### Is this a certified Gilbarco partnership? No, and we will not imply one. Gilbarco Passport is a product of Gilbarco Veeder-Root, and RankShield Financial is an independent platform with no affiliation, certification, or endorsement from them. What this page describes is an integration architecture built on interfaces a Passport site already exposes to its operators — your journal data and your processor reporting are yours to direct. If a deployment ever calls for a deeper interface than the standard exports provide, that conversation happens transparently with you and your vendors, not around them. ### What fraud does this actually catch at a fuel site? The three store-level patterns that hit fuel retail hardest. Card testing: a stolen-card batch being validated with small authorizations at an unattended pump at night, visible as an authorization-velocity break on one terminal. Skimming: a shimmer inside one dispenser forcing chip reads to fail over to magstripe, visible as a fallback-rate spike on that pump while its neighbors read chips normally. And register-level leakage: refund and void chains flowing to a single destination card across a shift. Each detection produces a sealed verdict with the evidence chain attached, so the response — isolating a terminal, inspecting a reader, reviewing a shift — starts from proof rather than suspicion. ### How fast can a Passport chain get to a first result? Faster than a store project, because Phase 1 is a data exercise. A chain whose sites roll up to a back office can export sixty to ninety days of NAXML journal history from that one system, pair it with authorization-detail history from the processor, and RankShield runs the full rule set offline. The deliverable is a findings report: what would have been flagged, at which stores, on which terminals, with what verdicts. No site is visited and no terminal is touched to produce it, which is what lets the historical baseline begin the week the data-access agreement is signed rather than after a rollout. ### Does this work across a mixed estate of POS vendors? Yes, and it is a core reason the architecture is feeds-first. Because RankShield consumes the NAXML journal and ISO 8583 authorization data rather than installing vendor-specific software on registers, a Passport site, a Verifone site, and whatever an acquisition brought all land in one correlation layer. That matters beyond convenience: distributed attacks deliberately spread activity across stores, and a fraud layer blind to one vendor has holes exactly where an attacker would place the traffic. One coherent per-terminal view across the whole estate is what makes fleet-level detection tractable.