Hogy lehetnének jobbak a MÁV applikációi?

Vitézy Dávid közlekedési miniszteri kinevezésével új helyzet állt elő a magyar közlekedési digitális szolgáltatások körül. A miniszter beiktatása előtti interjújában maga is kiemelte, hogy „leállították a vonatinfót, amin követni lehetett a vonatokat, elrejtették a késési statisztikákat… ezeket nyilván mind helyre kell hozni”. Az érdemi kérdés azonban nem az, hogy mely megszüntetett szolgáltatásokat állítják helyre egyenként, hanem hogy milyen szerkezeti döntés szabadítja fel azt a fejlesztési kapacitást, amely a magyar piacon évek óta rendelkezésre áll, csak nem fér hozzá a megfelelő adatokhoz – és milyen strukturális keret garantálja, hogy az ilyen leállítások és visszalépések a jövőben ne legyenek lehetségesek pusztán egy vezetői aláírással.

A javaslatunk egyetlen, törvényi szinten elrendelhető lépés: a MÁV jegyértékesítési rendszerének (JÉ) alkalmazásprogramozási felületét (API-ját) tegyék nyilvánossá, dokumentálttá és piaci szereplők számára hozzáférhetővé, megfelelő szabályozási garanciákkal. Ez nem technikai részletkérdés, hanem az elmúlt évtized magyar közlekedés-informatikai diszfunkciójának legtisztábban orvosolható eleme — és olyan lépés, amely az uniós szabályozással összhangban, sőt annak szellemén túlmutatva állítaná helyre a versenyt a hazai közlekedési appok piacán.

A diagnózis: nem szakértelem-, hanem hozzáférési probléma

A MÁVPlusz mobilalkalmazás 1,7-es átlagos felhasználói értékelést kap a Google Play áruházban, csaknem ötezer vélemény alapján. A vonatinfó alkalmazás 2025 nyári megszüntetése után – amikor az utasok hirtelen elvesztettek egy hosszú éveken át megszokott, jól működő szolgáltatást – napokon belül megjelentek a piacon a független fejlesztők vonatinfó-klónjai. Ez utóbbi jelenség azért fontos, mert ugyanannak az érmének a két oldalát mutatja: a magyar piacon van fejlesztői kapacitás és szakértelem ahhoz, hogy gyorsan, használható közlekedési alkalmazás szülessen – feltéve, hogy hozzáfér a megfelelő adatokhoz.

A különbség pontosan ez. Az utazástervezés területén a MÁV az EMMA rendszert nyílt forrású, nemzetközileg elterjedt technológiára (az OpenTripPlanner utazástervező motorra) építette, és a menetrendi adatait GTFS, a valós idejű járműpozícióit GTFS-Realtime formátumban közzéteszi a magyar Nemzeti Hozzáférési Ponton (napportal.kozut.hu). Ez ugyanaz a formátum, amelyen a BKK is publikálja a fővárosi közösségi közlekedés adatait. Az EMMA OpenTripPlanner-motorja egyúttal jól dokumentált GraphQL-felületet is biztosít — ezért tudtak külső fejlesztők napokon belül vonatinfó-klónokat építeni a vonatinfó-app megszűnését követően.

A jegyértékesítés területén azonban — ahol a JÉ rendszer API-ja zárt, és kizárólag a MÁV által üzemeltetett frontendek (a MÁVPlusz, a régi MÁV-applikáció, a jegy.mav.hu, az automaták és a kalauz-applikáció) férhetnek hozzá —

egyetlen szereplő próbál minden funkciót, minden felhasználói igényt és minden hibajavítást egyetlen alkalmazásban kezelni. Az eredmény az a többéves fejlesztési backlog, amely láthatóan meghaladja a belső csapat kapacitását, és amelyet külső fejlesztők bevonásával sem oldottak meg, mert a hozzáférés szabályozatlan és informális.

A piaci kapacitás létezik. Az utazástervezési adatokhoz a hozzáférés is megvan. A jegyértékesítési adatokhoz nincs – és pontosan ez az a réteg, amely a MÁVPlusz minőségi problémáit termeli.

A precedens: Budapest GO és a motiváció kérdése

A Budapest GO alkalmazás története közelebbről tanulmányozva tanulságos. Önmagában az adatok nyitottsága – a FUTÁR menetrendi és valós idejű adatainak GTFS és GTFS-Realtime formátumú közzététele – szükséges, de nem elégséges feltétele volt a sikernek. A jegyértékesítési oldalon ugyanis a BKK kötött volt a Nemzeti Mobilfizetési Rendszerhez (NMFR), amelyen keresztül egyébként számos kereskedelmi alkalmazás (OTP Simple, Telekom, valamint maga a NMFR Mobiljegy applikációja) is árulta a BKK-jegyeket. Ezek mindegyike ugyanazt a központi backendet integrálta — és mindegyik mérhetően gyengébb terméket állított elő, mint a Budapest GO. Ugyanazok az adatok, ugyanaz a backend, drasztikusan eltérő végeredmények.

A különbséget nem a struktúra önmagában termelte ki, hanem az aktorok motivációja. A BKK új vezetése saját relevanciáját akarta bizonyítani az utasok és a politika felé; a Realcity–Supercharge–T-Systems konzorcium pedig a hozzáadott értékét a BKK felé. Ez a kettős relevancia-bizonyítás generálta azt a kreatív energiát — a NMFR korlátozott, gyakorlatilag csak átszínezhető API-jának kreatív integrációját, a FUTÁR-térképes adatok és a jegyértékesítés egyetlen felületen történő egyesítését —, amire a többi NMFR-frontendet építő szereplő nem fektetett erőforrást, mert számukra ez nem volt presztízskérdés. A Budapest GO-t 2024 februárjában a HWSW olvasói szavazásán az év applikációjának választották.

A tanulság szempontjából ez fontos finomítás: a nyitott platform nem garantálja a minőséget, csak megteremti a lehetőséget, hogy létrejöjjön. A minőséget végső soron a szereplők motivációja termeli ki – és a piaci verseny pont egy olyan strukturális helyzetet hoz létre, amelyben a minőségi termék előállítása presztízskérdéssé tud válni.

Egy belső monopóliumban – ahol az alkalmazás úgyis az „elsődleges csatorna”, függetlenül attól, hogy jó vagy rossz – ez a motiváció szerkezetileg hiányzik. A MÁVPlusz 1,7-es értékelése nem véletlen.

A MÁV jelenlegi modellje részben ennek a fordítottja. Az utazástervezést – ahol nem áll fenn jelentős tranzakciós vagy árazási érdek – egy nyitott technológiai stackre építette (OpenTripPlanner, GTFS-bemenettel, GraphQL API-val), amelyhez kívülről hozzá lehet férni, és ez generálta a klón-alkalmazások egészséges versenyét. A jegyértékesítést – ahol a tényleges piaci érték képződik – zártan, és belső fejlesztésű frontendekkel próbálja kiszolgálni. A két modell minőségi különbsége az utasok mindennapi tapasztalata. Az értékelési pontszámok közti különbség nem a fejlesztők képességének függvénye; a két rendszer közötti szervezeti és szabályozási különbségé.

Az EU-keret támogató környezetet ad

Az érv nem új a magyar közlekedéspolitikában, és nem is hazai sajátosság. Az Európai Unió 2010 óta – az ITS-irányelvvel (2010/40/EU) és annak végrehajtási jogszabályaival – fokozatosan építi azt a keretet, amely a közlekedési adatokat nyitott, szabványos formában követeli meg a tagállamoktól. A 2017/1926/EU delegált rendelet kötelezi a tagállamokat egy Nemzeti Hozzáférési Pont (National Access Point, NAP) létrehozására, amelyen keresztül a multimodális utazási adatokat – menetrend, hálózat, megállók, akadálymentesség, alapvető díjszabási adatok, üzemzavarok, megfigyelt késések és járatkimaradások – gépileg feldolgozható, szabványos formátumban elérhetővé kell tenni.

A 2023 novemberében elfogadott 2024/490/EU módosítás kiterjesztette a kötelező adatkört, és a dinamikus üzemzavari és késési adatokra 2025. december 1-jei, a megfigyelt késési és kimaradási adatokra szintén 2025. december 1-jei határidőt szabott. Magyarországon a NAP a Magyar Közút Nonprofit Zrt. által üzemeltetett napportal.kozut.hu portál, amelyen ma a MÁV vasúti és buszos menetrendje, valamint a vonatok és buszok valós idejű járműpozíciói érhetők el GTFS és GTFS-Realtime formátumban.

Itt érdemes egy gyakran felmerülő érvet előre tisztázni. A MÁV részéről időnként elhangzik, hogy a késési és üzemzavari információk amúgy is elérhetők, hiszen a MÁVPlusz felületén megjelennek, illetve a MÁV-csoport havonta közzétesz egy összesített pontossági riportot. Ez azonban nem teljesíti az adatközzétételi kötelezettség értelmét. A 2017/1926/EU rendelet 2. cikke explicit definíciót ad: az adatok elérhetősége azt jelenti, hogy az adatokat „bármikor lekérdezhetően, gépileg feldolgozható digitális formátumban” kell elérhetővé tenni. Egy felhasználói felületen megjelenő késési információ vagy egy havi PR-anyag formájában közzétett összesített statisztika – bármilyen részletes is – definíciószerűen nem teljesíti ezt. A NAP-rendszer egész logikája az, hogy az adat fejlesztők, kutatók, sajtó és piaci szereplők számára is integrálható legyen; a strukturált formátum éppen az, ami az adatközzétételt egyszeri PR-akcióból tartós infrastruktúrává teszi.

A jegyértékesítési tranzakciós (booking) API jelenleg uniós szabályozási fehér folt — ezzel a CER (a közösségi vasúttársaságok szövetségének) Open Sales and Distribution Model (OSDM) projektje és az Európai Bizottság 2023 novemberi Multimodal Digital Mobility Services (MDMS) javaslatcsomagja foglalkozik. Ezen a területen Magyarországnak nincs várnia kötelezettsége — a hazai jogalkotó proaktívan, az uniós irányt megelőzve léphet. Az elmúlt évtized magyar közlekedési digitális gyakorlata megmutatta, hogy az EU-szabályozási irány önmagában nem hozza el a változást: a hazai szabályozói akarat kell hozzá.

A javaslat: a JÉ API megnyitása platformként

Konkrétan három, egymással összefüggő szabályozási lépést javaslunk.

Az első: a JÉ rendszer API-jának nyilvánossá tétele, dokumentált, verziózott és szolgáltatási szint-megállapodással (SLA-val) ellátott formában, az OSDM szabványához igazítva. Az API-nak két, eltérő hozzáférési feltételekkel működő szintje legyen. Az olvasási réteg – a menetrend, az árlekérdezés, a kedvezményrendszer – ingyenesen vagy névleges díj ellenében bárki számára hozzáférhető, megfelelő rate limit mellett. A tranzakciós réteg – a tényleges jegyértékesítés – jutalék-alapú elszámolással, regisztrált és tanúsított piaci szereplők számára. Ez a modell ismert a NAV, az OEP és más állami szervek online adatszolgáltatásainál, és technikailag jól megoldott.

A második: a MÁVPlusz pozíciójának átalakítása – nem a megszüntetésével, hanem a strukturális privilégiumai megszüntetésével. A MÁVPlusz ma sem belső fejlesztés a szó szigorú értelmében: a MÁV nyíltan vállalja, hogy külső fejlesztői partnerek építették – csak éppen a fejlesztők és tervezők neve nem nyilvános, és maguk sem hivatkoznak rá referenciaként. Ennek ellenpéldája a Melher Dóra által fémjelzett, a Dot creative ügynökség saját portfóliójában büszkén szerepeltetett MÁV internetes jegyértékesítés, amely 2020 december óta érhető el.

A különbség nem az, hogy ki fejleszt, hanem hogy ki vállalja.

Ezen javaslatunk ezért további két, egymástól elválaszthatatlan részelemből áll. Egyfelől: a MÁVPlusz továbbra is létezhet, sőt a MÁV mint közlekedési szolgáltató természetesen reklámozhatja is – ahogy a BKK is folyamatosan reklámozza a Budapest GO-t a saját felületein –, de nem lehet az egyetlen legitim csatorna, és a fejlesztése nem élvezhet többé strukturális versenyelőnyt a JÉ API-hoz való kizárólagos hozzáférés formájában. Minden, amihez a MÁV alkalmazásai hozzáférnek, kontrollált körülmények között – a NAV számlázóprogramoknál, az EESZT egészségügyi rendszereknél vagy az NTAK vendéglátói szoftvereknél már bevezetett tanúsítási mintájához hasonlóan – elérhetőnek kell lennie tetszőleges piaci szereplőnek.

Másfelől: minden közfeladatot ellátó digitális szolgáltatásban – a MÁVPluszban, a JÉ-rendszer minden frontendjében, a NAP-on, és minden külső fejlesztésben – kötelező legyen a fejlesztői és tervezői stáblista közzététele. A jó munkát a fejlesztők a saját portfóliójukba ki tudják rakni; a rosszért legalább valaki név szerint vállalja a felelősséget. Ez a fajta szakmai elszámoltathatóság az, ami a versenyt nem csak strukturálisan, hanem motivációs szinten is biztosítja: ahogy a Budapest GO esetében, itt is a kettős relevancia-bizonyítás – a megrendelő intézmény és a fejlesztők egymás felé és az utasok felé – generálhatja azt a minőséget, amit egy névtelen, számonkérhetetlen monopol-fejlesztéstől szerkezetileg nem lehet várni.

A harmadik: a MÁV mint szervezet platformüzemeltetői képességeinek megerősítése. Ez nem ugyanaz, mint az applikációfejlesztői képesség. A MÁV jegyértékesítési részlegének az API üzemeltetése, a szabványok karbantartása, a piaci szereplők tanúsítása és auditálása kell legyen a feladata. Egy fejlesztői dokumentáció, egy szolgáltatásiszint-megállapodás, egy verziókezelési politika – ezek a platformüzemeltetői munka termékei, és ezek minőségében dől el, hogy a JÉ API megnyitása valódi piaci nyitást hoz, vagy csak papíron lesz az.

Az aktualitás: a következő hónapok döntései

A platform-modell felépítése nem évek munkája. A JÉ rendszer API-ja létezik – több is –, csak nem nyilvános. A dokumentációs és tanúsítási folyamat kialakítása hónapok kérdése. A vasúti szektorra szabott OSDM egy európai szabványra ad alapot, amelyet a MÁV egyébként is implementálni fog az uniós kötelezettségek miatt – a kérdés csak az időzítés és a hozzáférés körének rendezése.

A jelenlegi pillanat ráadásul azért is kedvez egy ilyen nyitásnak, mert a fejlesztői belépési küszöb történelmi mélypontra süllyedt. A nagy nyelvi modellek alapú kódgeneráló eszközök elmúlt két éves elterjedésével az, ami öt éve még egy közepes méretű fejlesztői csapat hónapokig tartó munkáját igényelte, ma egyetlen fejlesztő néhány napos feladata. Az érvelés, amely a közlekedési platformok belső monopóliumát egyébként is gyenge lábakon álló kapacitás-hiányos alapokra építette, ebben az új környezetben végképp tarthatatlan.

A miniszter első száz napjának egyik legfontosabb döntése lesz, hogy a következő évtized a kisgömböc-modell folytatása-e – egyetlen, mindent magába olvasztó belső alkalmazás évekre tornyosuló backlogjával –, vagy egy versenyző piac, amelyben a magyar utasok végre olyan minőségű digitális szolgáltatásokat használhatnak, mint amilyenek a budapesti közösségi közlekedésben már elérhetők. Az infrastruktúra megvan. A szakértelem megvan. Az európai szabályozási irány megvan. Egy szabályozói döntés választja el az utasokat attól, hogy ez a kapacitás a szolgálatukba álljon.

A szerző a MÁV jegyértékesítési automatáinak UX-szakértője, a HKIR/EGYJEGY integrációs vezetője, az utas.hu alapítója.