Anti-fraud tīkla API Eiropā: kāpēc ar kopīgu sintaksi nepietiek

Ar “anti-fraud network API” šajā rakstā saprotu saskarni, ar kuru autorizēts patērētājs var saņemt šauri definētu tīkla vai ar tīklu saistītu signālu krāpniecības riska izvērtēšanai.

Tas nav tas pats, kas centralizēta datubāze ar personām, telefona numuriem un krāpniecības vēsturi.

GSMA Open Gateway un CAMARA pieeja jau demonstrē, ka tīkla spēju var izteikt kā standartizētu API. Piemēram, SIM Swap API ļauj pārbaudīt, vai noteiktā periodā konkrētai mobilajai līnijai veikta SIM maiņa, savukārt Number Verification API paredz tīkla līmeņa pārbaudi, vai lietotāja norādītais mobilais numurs atbilst ierīcei piesaistītajam numuram.23

Abos gadījumos aplikācijai nav nepieciešams saņemt visu operatora telemetriju. Tai vajag konkrētu atbildi uz konkrētu jautājumu.

Šo principu var paplašināt arī uz citiem anti-fraud signāliem, bet tas jādara piesardzīgi.

Krāpniecības novēršanas sistēmās ļoti viegli sajaukt dažādas pierādījumu kategorijas.

Šī robeža nav semantiska pedantija.

Ja aplikācija tīkla faktu pārvērš par kategorisku secinājumu “fraud=true”, tā sev piesavinās daudz vairāk nozīmes, nekā sākotnējais avots ir sniedzis. Tas palielina kļūdaini pozitīvu rezultātu risku un sarežģī atbildības sadalījumu.

Tāpēc labi projektētā sadarbspējas profilā būtu jābūt iespējai saglabāt signāla klasi, ne tikai vērtību.

BEREC 2026. gada aicinājums tieši jautāja, cik lielā mērā tīkla API patiesībā ir sadarbspējīgas starp operatoriem un dažādiem tīkla iekārtu piegādātājiem.1 Šo jautājumu nav iespējams korekti atbildēt tikai ar “visi izmanto CAMARA”.

Sadarbspēju vajag sadalīt slāņos.

Pirmie divi vai trīs slāņi ir tie, ko visvieglāk demonstrēt sandbox vidē.

Krāpniecības novēršanai bieži izšķiroši ir tieši nākamie.

Šī ir viena no bīstamākajām integrācijas kļūdām.

Pieņemsim, ka API pārbauda, vai zvana izcelsmes konteksts ir saderīgs ar uzrādīto numuru. Atbilde varētu būt:

• CONSISTENT;
• INCONSISTENT;
• NOT_AVAILABLE.

Ja aplikācijas izstrādātājs trešo rezultātu tehnisku ērtību dēļ pārvērš par false, tas vairs nenozīmē “neatbilstība nav konstatēta”. Tas nozīmē “mēs nezinām, vai neatbilstība ir”.

Anti-fraud sistēmā šī atšķirība ir kritiska.

Tas pats attiecas uz:

• operators šo spēju neatbalsta;
• dati nav pietiekami svaigi;
• pārbaude beidzās ar timeout;
• lietotājam vai aplikācijai nav tiesību saņemt rezultātu;
• konkrētais numurs nav atrodams attiecīgajā avotā;
• avots nevar sniegt pietiekamu pārliecību.

Šos stāvokļus nevajag saplacināt vienā false.

Portatīvai anti-fraud semantikai vajag atsevišķi saglabāt negatīvu rezultātu, nezināmu stāvokli, neatbalstītu spēju un pagaidu nepieejamību.

Ja anti-fraud signāls tiek saņemts tieši no operatora, pārsūtīts caur agregatoru, kešots mākoņpakalpojumā un tad izmantots bankas vai platformas lēmumā, ar pašu vērtību nepietiek.

Patērētājam vajag zināt vismaz:

• kas sākotnēji izdeva signālu;
• kāda veida avots tas ir;
• kad novērojums veikts;
• kāda noteikumu vai politikas versija izmantota;
• cik ilgi rezultāts uzskatāms par aktuālu;
• vai rezultāts vēlāk atsaukts, labots vai aizstāts.

Es šo kopumu saucu par provenance un freshness slāni.

RISK bez avota un laika var būt praktiski bezvērtīgs. Vēl sliktāk — tas var būt bīstams, jo izskatās autoritatīvāks, nekā patiesībā ir.

Agregatori un channel providers ir svarīgi tīkla API tirgū. Tie var atrisināt discovery, routing, komerciālo līgumu un vienotas integrācijas problēmas.

Tomēr agregācija nedrīkst izdzēst signāla izcelsmi.

Ja operators ir tas, kurš tieši novēro SIM maiņu, roaming stāvokli vai citu tīkla faktu, agregators var šo informāciju nogādāt izstrādātājam, bet tam nevajadzētu kļūt par “patiesības avotu” tikai tāpēc, ka API pieprasījums tehniski tika nosūtīts agregatora endpointam.

Tā pati problēma parādās valsts reģistros un politikas sarakstos.

Tāpēc sadarbspējas profilam ir jāprot saglabāt issuer un source class, ne tikai pakalpojuma sniedzēju, caur kuru rezultāts tika saņemts.

Daži dati mainās reti. Citi kļūst nederīgi minūtēs.

SIM Swap signāls var būt nozīmīgs tieši tāpēc, ka notikums ir svaigs. Numura vai sender-ID politikas statuss var tikt mainīts. Riska signāls var būt atsaukts pēc kļūdaini pozitīva rezultāta. Viesabonēšanas vai izcelsmes konteksts var mainīties starp diviem notikumiem.

Tāpēc observed_at, valid_until vai līdzvērtīgs freshness mehānisms anti-fraud API nav kosmētisks.

Ja atbildes tiek kešotas vai izplatītas federētā sistēmā, jāparedz arī labojuma ceļš:

ja pirmavots maina vai atsauc rezultātu, cik ātri šī korekcija sasniedz tos, kuri iepriekšējo rezultātu izmantoja?

Bez šī mehānisma standartizēta API var standartizēti izplatīt novecojušu kļūdu.

Viena skaitļa priekšrocība ir acīmredzama. Aplikācija saņem risk=82 un piemēro slieksni.

Problēma ir tajā, ka divu pakalpojumu 82 var nozīmēt pilnīgi dažādas lietas.

Viens modelis var balstīties uz SIM maiņu, otrs uz zvana izcelsmes neatbilstību, trešais uz lietotāja uzvedību, ceturtais uz ārēju melno sarakstu. Mainoties modelim, tas pats skaitlis var mainīt nozīmi, pat ja API shēma paliek nemainīga.

Tāpēc publiskajā BEREC iesniegumā es piedāvāju kopīgiem anti-fraud profiliem prioritizēt reason codes un evidence class, nevis vienu necaurspīdīgu universālu fraud score.4

Riska modelis var pastāvēt. Taču portatīvā slānī jābūt iespējai saprast, uz kāda veida signāliem lēmums balstās.

Tīkla operatoram var būt nepieciešami noslodzes, maršrutēšanas, atrašanās vietas vai citi aizsargāti dati, lai novērtētu konkrētu anti-fraud jautājumu. No tā neizriet, ka šie jēldati jādod aplikācijas izstrādātājam.

ePrivacy direktīvas 6. pants noslodzes datiem nosaka īpašu režīmu; tā 5. punkts starp apstrādes funkcijām, kuras veic personas, kas darbojas elektronisko sakaru pakalpojumu sniedzēja pakļautībā, min arī krāpšanas atklāšanu, taču tas nerada vispārēju tiesību nodot jēldatus ārējiem patērētājiem.5 Ja tiek apstrādāti personas dati, paralēli jāievēro GDPR nolūka ierobežojuma, datu minimizēšanas un tiesiskā pamata prasības.6

No arhitektūras viedokļa drošs noklusējums daudzos gadījumos ir tas, ko savā BEREC iesniegumā nosaucu par local resolve:

1. pirmavots analizē aizsargāto tīkla kontekstu savā vidē;
2. tas atbild uz konkrētu, iepriekš definētu jautājumu;
3. ārpus pirmavota tiek izsniegts tikai minimāli nepieciešamais rezultāts un tā provenance.

Piemēram, bankas krāpniecības kontrolei var būt vajadzīgs fakts, ka uzrādītā komunikācijas identitāte nav saderīga ar pieejamo tīkla izcelsmes kontekstu. Tai ne obligāti vajag saņemt pilnus signalizācijas vai atrašanās vietas ierakstus.

“Local resolve” šeit ir dizaina priekšlikums, ne ES tiesību aktos definēta prasība.

Tehniskais slānis nedrīkst klusējot pārvērst riska novērtējumu par juridisku lēmumu.

Eiropas Elektronisko sakaru kodeksa 97. panta 2. punkts paredz dalībvalstīm nodrošināt, ka kompetentās iestādes var konkrētos gadījumos pieprasīt elektronisko sakaru pakalpojumu sniedzējiem bloķēt piekļuvi numuriem vai pakalpojumiem, ja tas ir pamatots ar krāpšanu vai ļaunprātīgu izmantošanu.7

Tas ir juridisks mehānisms.

Savukārt aplikācijas saņemts INCONSISTENT, RISK_SIGNAL vai līdzīgs API rezultāts ir tehnisks ievaddats lēmumu procesā. Tas var izraisīt papildu pārbaudi, brīdinājumu vai citu samērīgu kontroles darbību, bet pats par sevi nekļūst par kompetentas iestādes rīkojumu.

Šo robežu ir vērts nostiprināt pašā datu modelī, nevis atstāt dokumentācijas piezīmē.

Krāpniecības novēršanas sistēmas mēdz apspriest detection rate. Mazāk uzmanības tiek pievērsts tam, kas notiek, kad signāls ir nepareizs.

Ja viens operators labo kļūdainu statusu, bet agregators to turpina kešot, sadarbspēja ir salūzusi.

Ja lietotājam ir iespējams panākt labojumu pie sākotnējā avota, bet nav mehānisma, kā labojums propagējas tālāk, sistēma nav pabeigta.

Tāpēc labam profilam vajag:

• supersession vai revocation semantiku;
• correction timestamp;
• skaidru pirmavotu;
• noteiktu labojuma izplatīšanas laiku;
• redress ceļu gadījumiem, kad kļūdains signāls rada būtisku negatīvu efektu.

Tas ir īpaši svarīgi, ja anti-fraud API sāk izmantot ne tikai telekomunikāciju operatori, bet bankas, platformas, CPaaS pakalpojumi un citi sektori.

BEREC 2026. gada aicinājums tieši atzina GSMA Open Gateway un CAMARA par būtisku šīs ekosistēmas pamatu.1

Tāpēc anti-fraud interoperabilitātes modelim nav jēgas veidot konkurējošu API steku.

Esošās spējas, piemēram, SIM Swap un Number Verification, jāizmanto tur, kur tās risina konkrēto jautājumu.23 Papildu darbs vajadzīgs tur, kur pašreizējās API neatbild uz visu nepieciešamo semantiku vai kur vairāku spēju kombinācija jāpadara portatīva.

Piemēram, šādi jēdzieni var būt atsevišķa sadarbspējas profila priekšmets:

• zvana izcelsmes / uzrādītās identitātes konsekvence;
• aizsargāta vai do-not-originate numura politikas statuss;
• alfanumeriska SMS sūtītāja autorizācijas statuss;
• izcelsmes un viesabonēšanas konteksta konsekvence;
• signāla freshness, correction un revocation;
• riska novērtējuma evidence class.

Šie punkti manā BEREC iesniegumā bija priekšlikumi, ne apgalvojums, ka tie jau ir standartizēti CAMARA API.4

Latvija ir labs piemērs, kāpēc priekšizpētei jāsākas ar esošo spēju kartējumu.

BEREC 2025. gada ziņojums par numerācijas ļaunprātīgas izmantošanas un krāpniecības problēmām fiksēja, ka Latvijas regulators SPRK apsvēra decentralizētu anti-fraud API risinājumu zvanu izcelsmes leģitimitātes pārbaudei un ka Latvija izmēģināja Lietuvā un Igaunijā izmantotu pieeju ar pārrobežu potenciālu.8

2026. gada 24. augustā es atsevišķi vērsos pie SPRK, Satiksmes ministrijas un SIA “Elektroniskie sakari”, piedāvājot izvērtēt sadarbspējas modeli komunikācijas identitāšu un krāpniecības signālu apmaiņai.9

No atbildēm izrietēja divi svarīgi fakti.

Pirmkārt, SPRK 4. septembra atbildē norādīja, ka Latvijas mobilo sakaru operatori jau ir izstrādājuši un ieviesuši kopīgu tehnisku numerācijas krāpniecības novēršanas risinājumu numuru izmantošanas atbilstības pārbaudei un ka ar to bloķēti vairāki miljoni krāpniecisku vai neatbilstošu zvanu mēģinājumu.10

Otrkārt, SIA “Elektroniskie sakari” norādīja, ka publiskā Numerācijas datubāzes informācija ir pieejama uzņēmuma tīmekļvietnē un Latvijas Atvērto datu portālā, bet manā iesniegumā piedāvātā atsevišķā mašīnlasāmā datu apmaiņa vai API piekļuve datubāzei nav paredzēta un tās ieviešana nav plānota.11

Šie fakti nav arguments, ka “Latvijai vajag vēl vienu API”.

Tieši otrādi. Tie parāda, kādai jābūt priekšizpētei: vispirms jānoskaidro, kuras vajadzīgās funkcijas jau nodrošina operatoru risinājumi, reģistri un esošie kanāli, un tikai tad jāmeklē neatrisināta sadarbspējas plaisa.

Satiksmes ministrija 4. septembrī manu priekšlikumu iekļāva 23. septembra nozares sanāksmes darba kontekstā un aicināja to prezentēt, tostarp komunikācijas identitāšu, krāpniecības signālu un iespējamo sadarbspējas risinājumu daļu.12 Tas pats par sevi nav politikas lēmums vai risinājuma apstiprinājums.

Elektronisko sakaru likuma 64. pants nosaka numerācijas krāpniecības regulējuma pamatu, tostarp informācijas apriti starp operatoriem un regulatoru, kā arī pienākumu konstatētas numerācijas krāpniecības vai nepareizas izmantošanas gadījumā pārtraukt attiecīgo izsaukumu maršrutēšanu un piekļuvi.13

Tas pats likums nosaka Numerācijas datubāzi kā valsts informācijas sistēmu.13

Šīs normas pašas par sevi nerada izstrādātājiem paredzētu anti-fraud API. Tās tomēr nozīmē, ka Latvijā nav jāsāk ar tukšu lapu: numerācijas pārvaldībai, operatoru sadarbībai un krāpniecības ierobežošanai jau ir tiesiskas un tehniskas struktūras.

Sadarbspējas jautājums ir par to, ko no šīm spējām var droši un tiesiski izteikt portatīvā, minimizētā tehniskā formā.

Ja Eiropā tiktu veidots anti-fraud interoperability profile, es sāktu nevis ar jaunu “super API”, bet ar nelielu kopīgu līgumu par nozīmi.

Minimālais profils varētu noteikt:

1. Signāla tipu. Tīkla fakts, reģistra/politikas fakts, advisory risk assessment vai cits skaidri definēts tips.

2. Statusa semantiku. Pozitīvs, negatīvs, nezināms un nepieejams rezultāts netiek sapludināti.

3. Provenance. Issuer, source class un vajadzības gadījumā starpnieks.

4. Laiku. Observation time, freshness/expiry un correction/revocation.

5. Reason code. Kāpēc saņemts tieši šāds rezultāts, neizpaužot vairāk datu, nekā nepieciešams.

6. Versiju. Kurai noteikumu, politikas vai modeļa versijai rezultāts atbilst.

7. Juridiskā efekta klasi. Tehnisks signāls nevar izskatīties pēc juridiski saistoša bloķēšanas vai izpildes lēmuma.

Ar to jau pietiek, lai dažādu operatoru un agregatoru rezultātus varētu salīdzināt daudz drošāk.

API sertifikācija tikai pēc shēmas šeit būtu pārāk vāja.

Pilotā vajadzētu izmantot vienus un tos pašus sintētiskos testus pie vairākiem operatoriem vai agregatoriem un pārbaudīt:

• vai vienāds gadījums rada semantiski līdzvērtīgu rezultātu;
• vai UNKNOWN nekad nepārvēršas par “safe”;
• vai avots un observation time saglabājas visā ķēdē;
• vai atsaukts vai labots signāls propagējas noteiktā laikā;
• vai viena API sniedzēja nomaiņa neprasa pārrakstīt pamatlēmumu loģiku;
• vai jēldati netiek eksportēti, ja pietiek ar minimizētu apgalvojumu;
• vai aplikācija nevar sajaukt advisory signālu ar juridisku bloķēšanas rīkojumu;
• vai audita pierādījums ļauj atjaunot, kas, kad un pēc kādiem noteikumiem izdeva rezultātu.

Tikai tad “interoperable” sāk nozīmēt vairāk par vienādu OpenAPI failu.

BEREC nav Eiropas krāpniecības policija un tam nevajadzētu kļūt par centrālu jēldatu operatoru.

Taču BEREC ir dabiska vieta jautājumiem, kuri rodas starp nacionālajiem regulatoriem un operatoriem: portabilitāte, pārrobežu sadarbspēja, tirgus piekļuves nosacījumi, operatoru/aggregatoru lomas un tehnisko spēju konsekvence.

2026. gada aicinājumā BEREC tieši prasīja informāciju par ekosistēmas lomām, API ieviešanas šķēršļiem, regulatīvajiem izaicinājumiem un faktiskās sadarbspējas līmeni.1 Mans publiskais iesniegums ar anti-fraud interoperability profile 23. augustā tika publicēts BEREC konsultācijas materiālos.4

BEREC 2026. gada darba programma paredzēja pēc aicinājuma sagatavot kopsavilkuma ziņojumu vēlāk 2026. gadā.14 Uz šā raksta statusa pārbaudes datumu — 25. septembri — BEREC publiskajā reģistrā ir publicēti saņemtie ieguldījumi, bet šā darba gala kopsavilkuma ziņojums vēl nav publicēts.15

Tāpēc pagaidām ir korekti runāt par iesniegtu priekšlikumu un notiekošu BEREC darba virzienu, nevis par BEREC pieņemtu anti-fraud API politiku.

Eiropas tīkla API standartizācija ir nepieciešama, bet krāpniecības novēršanā sintakse ir tikai pirmais slānis.

Patiesā sadarbspēja sākas tad, kad dažādi operatori, agregatori un aplikācijas vienādi saprot:

ko signāls nozīmē, kas to izdeva, cik tas ir svaigs, ko nozīmē nezināms rezultāts, kā kļūda tiek labota un kādu juridisku efektu rezultātam nedrīkst piedēvēt.

Ja šo slāņu nav, viena un tā pati API forma var paslēpt atšķirīgas un savstarpēji nesalīdzināmas realitātes.

Anti-fraud ekosistēmai tāpēc nav vajadzīga vēl viena centrāla datubāze. Tai vajag pietiekami precīzu kopīgu valodu, lai jau esošos tīkla, reģistru un riska signālus varētu izmantot pāri operatoru un valstu robežām, nezaudējot to nozīmi.

Publiskie un tiesiskie avoti pārbaudīti 2026. gada 25. septembrī. Rakstā piedāvātie anti-fraud assertion semantikas elementi ir autora priekšlikums, nevis BEREC, CAMARA vai GSMA apstiprināts standarts, ja vien pie konkrētā elementa nav norādīts citādi.

Šis raksts ir tehniskas, regulatīvas un sadarbspējas arhitektūras analīze, nevis individuāla juridiska konsultācija.