SeaSpoofFinder -- Potential GNSS Spoofing Event Detection Using AIS

SeaSpoofFinder – Potential GNSS Spoofing Ev ent Detection Using AIS J ´ on W inkel T om W illems Cillian O’Driscoll Ignacio Fernandez-Hernandez Abstract —This paper in vestigates whether lar ge-scale GNSS spoofing activity can be inferr ed from maritime A utomatic Identification System (AIS) position reports. A data-processing framework, called SeaSpoofFinder , a vail- able here: seaspooffinder .github .io/ais data , was developed to ingest and post-process global AIS str eams and to detect candidate anomalies thr ough a two-stage procedur e. In Stage 1, implausible position jumps ar e identified using kinematic and data-quality filters; in Stage 2, events are retained only when multiple vessels exhibit spatially con- sistent source and target clustering, thereby reducing false positives from single-vessel artifacts. The resulting final potential spoofing events (FPSEs) re veal recurr ent patterns in se veral regions, including the Baltic Sea, the Black Sea, Murmansk, Moscow , and the Haifa area, with affected footprints that can span large maritime areas. The analysis also highlights recurring non-spoofing artifacts (e.g., back- to-port jumps and data gaps) that can still pass heuristic filters in dense traffic regions. These r esults indicate that AIS-based monitoring can pro vide useful evidence f or identifying and characterizing potential spoofing acti vity at scale, while emphasizing that AIS-only e vidence does not provide definitive attribution. Index T erms —GNSS, Galileo, AIS, Spoofing I . I N T R O D U C T I O N The spoofing threat has been recognized in the GNSS community for more than two decades [1], [2], and operational manifestations have increased in recent years [3]. A number of large scale monitoring applications hav e pre viously been published that utilize the widely av ailable ADS-B data used in the aviation sector [4]– [6]. For maritime users, a comparable source is the Auto- matic Identification System (AIS), which distributes ves- sel reports in near real time through terrestrial receiving stations and satellite links. This work analyzes AIS position reports to identify patterns consistent with potential GNSS spoofing. AIS data alone cannot provide definitiv e attribution; howe ver , jon@wi-c.is tom.willems@cgi.com cillian@codc.ie Ignacio.FERN ANDEZ-HERN ANDEZ@ec.europa.eu characteristic spatial and temporal signatures can still be detected. In some regions, independent field observ ations hav e also been reported e.g., in the Kaliningrad area [7]– [9]. T o support this analysis, a prototype software tool was de veloped to collect, store, and post-process AIS network data. The results indicate recurrent patterns consistent with large-scale spoofing activity in sev eral regions, including the Baltic Sea (Kaliningrad and St. Petersbur g), Mur- mansk, the Black Sea, and the eastern Mediterranean. The presented results remain preliminary and include e vents that are difficult to classify . For e xample, in and around Amsterdam, Stockholm and Fort Lauderdale, FL, and other locations, the heuristics also flag e v ents that may correspond to non-spoofing data artifacts. I I . S E A S P O O F F I N D E R A software tool, SeaSpoofFinder , was dev eloped to capture and log AIS data (see Fig. 1). Subsequently , the heuristics described below are applied to identify potential spoofing ev ents. AIS data ha ve been collected continuously since mid-December 2025 until the time of this writing (mid February 2026). The data are processed in user-selectable batches of 1 or 3 days, and a date selector enables temporal navigation. Detected potential spoofing e vents are visualized in a 3D global view . The interface displays both potential spoofing ev ents (PSEs) and final potential spoofing e vents (FPSEs). For vessels associated with FPSE detections, full trajectories are recorded and displayed. In predefined areas of interest (red rectangles in Fig. 1), heatmaps of ov erall vessel traf fic are generated. SeaSpoofFinder is publicly a v ailable at seaspoof finder . github .io/ais data and is planned to remain accessible at least through June 2026. During this period, the data are updated daily . The tool is provided as-is and was de veloped as part of a small informal study; accordingly , it should not be considered a commercial-grade system. A. AIS P osition Reports (Messag es 1–3) The primary dynamic information broadcast by AIS- equipped vessels is con veyed in the position report Fig. 1. SeaSpoofFinder – Global vie w of detected potential spoofing e vents. Both PSEs and FPSEs are shown, as well as the full trajectory of ships associated with FPSEs. Data was accumulated over three days, 6-8 of January , 2026. messages (Messages 1, 2, and 3) as specified in Recom- mendation ITU-R M.1371-5, § 3.1 [10]. These reports are transmitted periodically and provide, among others, the vessel identifier or the Maritime Mobile Service Identity (MMSI), navigation status, speed and course ov er ground, as well as the GNSS-deriv ed position (latitude/longitude) with associated integrity and timing indicators. The payload for Messages 1–3 comprises 168 bits, where the ke y fields used in our analysis are summarized in T able I. The UTC time-stamp field provides only the second within the minute (0–59). V alues up to 63 are reserved for special conditions. This field is primarily used by the TDMA access scheme between vessels and receiving stations and does not represent a precise reception-time reference for this study . B. The AIS Data Source Used AIS data is typically recei ved by shore stations, ag- gregated, and redistrib uted through commercial and open providers. Some providers apply plausibility filtering, which can remo ve anomalies of interest. For this study , an as-unfiltered-as-possible feed was preferred. The provider used for our study is aisstream.io [11]. After applying for an API key , the data stream can be accessed via TCP/IP . The AIS data provided by aisstream.io is obtained from a network of global land- based stations with a typical signal range of approx- imately 200 km. Coverage varies with environmental conditions and topograph y , and global coverage is not T ABLE I M A IN FI E L D S O F A I S P O S I T I O N R E P O RT M E S S AG E S 1 – 3 ( [ 1 0 ] , § 3 . 1 ) . Field Meaning (units / notes) Message ID Message type (1–3) Repeat indicator Retransmission count (0–3) MMSI Unique vessel identifier Navigational status Under way , at anchor, etc. Rate of turn (R O T) Rate of change of heading Speed ov er ground (SOG) V essel speed (kn) Position accuracy (P A) High ( ≤ 10 m) vs. low ( > 10 m) Longitude / Latitude GNSS-deriv ed position (deg) Course ov er ground (COG) T rack angle (deg) T rue heading V essel heading (deg) UTC time stamp Seconds within the minute RAIM flag Receiv er integrity monitoring indi- cator Communication state Slot timing / channel access state uniformly achieved. V essels operating sev eral hundred kilometers of fshore may lack position reports. The net- work is sho wn in Fig. 2. The AISStream.io feed is deli vered as JSON records and includes additional metadata, such as vessel name and a provider-le vel timestamp. In our analysis, this metadata timestamp did not provide a reliable discrimi- nator for spoofing detection. Fig. 2. The global distribution of the AIS stations contributing to the AIS Coverage. Note that due to the varying station-to-station cov erage area, each location is just represented by a red dot [11]. C. Spoofing Detection Heuristics Inferring spoofing from large AIS position streams is non-tri vial and inherently uncertain. A simple pairwise jump detector between consecuti ve positions yields a large number of apparent “jumping” vessels in raw data. Closer inspection indicates that some records use non- unique or placeholder MMSIs, although MMSI is nomi- nally unique. These values frequently end with “000000” or “999999” and may be associated with generic labels (e.g., “FRENCH W ARSHIP” or “N A TO SHIP”). Such records are excluded. W e also observe jumps that are almost entirely aligned with longitude or latitude. These may arise from bit- le vel decoding or transmission errors in one coordinate component; therefore, they are filtered conservati vely . The detection logic is implemented in tw o stages. Stage 1 applies a set of necessary tests; all must be satisfied for an ev ent to be retained as a potential spoofing event. The Stage 1 detector is intentionally conserv ativ e and prioritizes reduction of false alarms, at the expense of potentially missing some true e vents. Stage 1 still produces many dif ficult-to-interpret e vents. Stage 2 therefore introduces spatial clustering constraints. Specifically , at least two vessels must exhibit jumps from a common source area (typically 10 km radius) to a near-identical destination area (typically 10 m radius), as illustrated in Fig. 3. This criterion is sub- stantially stricter than single-vessel jump detection and is consistent with scenarios in which multiple receiv ers are simultaneously affected by a common spoofing source. This clustering requirement excludes single-vessel e vents by construction. The potential spoofing detection heuristics are sum- marized below . For a vessel movement to be classified Fig. 3. Illustrating the moti v ation behind the clustering of suspicious jumps. The red area denotes the area that is subject to spoofing. The ships sail into this area (the colored lines showing their true path). When they lock onto the (same) spoofed signal, their receivers are assumed to indicate very similar positions. as a potential spoofing ev ent (PSE), all criteria must be satisfied. The criteria are ev aluated in the listed order . 1) Jump detection: Excessive distance between con- secuti ve positions, ∆ ρ n t : ∆ ρ n t > ∆ ρ max , where ∆ ρ n t = |  R n t −  R n t − 1 | and  R n t is the position of vessel n at time t . 2) Speed jump detection: Excessive implied speed, ∆ v n t : ∆ v n t > ∆ v max , where ∆ v n t = ∆ ρ n t / ∆ t . Here, ∆ t is deri ved from the UTC timestamp in the AISStream JSON metadata. 3) Axis-aligned jump filter: Discard jumps that are nearly purely N/S or E/W (potential coordinate bit errors). If the ratio between directional jump com- ponents exceeds a threshold, the e vent is discarded. 4) Zero-coordinate filter: Discard jumps for which any of the four coordinates (previous/current lati- tude/longitude) equals zero. 5) In v alid-seconds filter: Discard jumps if either the pre vious or current seconds value exceeds 59 s in the AIS position record of T able I. 6) In v alid or ambiguous MMSI: Discard ship iden- tifiers whose string representation ends with “000000” or “999999”. Potential spoofing events from step one are all written to a file, such that the clustering detection can be performed in post-processing. A step 1 potential spoofing e vent is recorded in the following form: 1) ship_id : Maritime Mobile Service Identity (MMSI). 2) distance_m , speed_mps : Detected jump and estimated velocity . 3) prev_lat , prev_lon : Pre vious latitude and longitude. 4) prev_time_utc : Timestamp of the previous position record in UTC reflecting the time of reception on the TCP/IP interface. 5) curr_time_utc : T imestamp of the current po- sition record in UTC reflecting the time of recep- tion on the TCP/IP interface. 6) curr_lat , curr_lon : Current latitude and lon- gitude. After all the step 1 PSEs hav e been analyzed and recorded, the second clustering step is performed: 1) Compare all pairs of ships and check if the distance between the pre vious positions (i.e. prev_lat , prev_lon of each ship) is smaller than a thresh- old, D s . D s is typically in the order of 10 km. 2) If the previous step passes, then check if the distance between the current positions (i.e. curr_lat , curr_lon of each ship) is smaller than a threshold, D t . D t is typically in the order of 10 m. 3) Since it is not possible to tell if the current or the previous coordinates are in the spoofing area or in the target area (i.e. the red or blue are in Fig. 3), all four 1 combinations of swapping current for previous are considered in the first two steps. An e vent that surviv es both stages is classified as a final potential spoofing ev ent (FPSE). An FPSE indicates consistency with the detection criteria, but it does not constitute definitiv e proof of spoofing. I I I . R E S U LT S Data from AISStream.io hav e been collected continu- ously since approximately mid-December 2025. Process- ing is performed routinely , and results are published at seaspoof finder .github.io/ais data/ . An example output is sho wn in Fig. 1. Gray lines correspond to Stage 1 detec- tions, while colored lines denote events that also satisfy Stage 2 clustering constraints. For clustered detections, full vessel trajectories (all reported positions) are also sho wn as small triangles indicating course over ground. The five red rectangles indicate areas of interest iden- tified through manual revie w . W ithin each rectangle, a heatmap of reported positions for all vessels is generated to provide contextual traffic density . On the webpage, unconfirmed events 2 and vessel tracks can be toggled on and off. The follo wing subsections examine representati ve cases in the Baltic Sea, Black Sea, eastern Mediterranean (Haifa area), Moscow , and Murmansk. Acti vity around 1 If we label the previous positions by 1 and 1 ′ and current 2 and 2 ′ where ′ distinguishes between vessels, then we have to check the combinations: [1 , 1 ′ ] , [1 , 2 ′ ] , [2 , 1 ′ ] , [2 , 2 ′ ] , because the spoofed area and the spoofed position are different. 2 Events that pass Stage 1 but not Stage 2. Amsterdam is also discussed, as it illustrates challenges related to data quality and false positiv es. A. The Baltic Sea Spoofing incidents in the Baltic Sea have been reported pre viously [7]. In our observations (mid- December 2025 to early February 2026), FPSEs are frequent in this region, primarily around Kaliningrad and St. Petersbur g. Fig. 4 sho ws the FPSEs along with the full path of ships that were detected with FSPEs. The data set was accumulated over three days: January 9-11 2026. The data is av ailable at [12]. Fig. 4. FPSE ev ents in the Baltic Sea, recorded on 9-11 January 2026. W ithin the red boxes heatmaps are generated from all ships trajectories. Fig. 4 sho ws a high concentration of FPSEs around Kaliningrad and St. Petersbur g. Sev eral eastbound trajec- tories appear nominal until passing Bornholm, the island south-east of Denmark, after which reported positions abruptly relocate tow ard the Kaliningrad tar get area. T o the east, transitions are also observed west of Estonia, where tracks appear to enter or leave the area of anomalous behavior . Broadly , a large corridor between Bornholm and Estonia e xhibits unstable reported posi- tioning. Additional e vents are observed near Stockholm; these are uncertain and may correspond to “back-to-port” jump artifacts (see Section III-G). Fig. 5 provides a zoomed view of events near Kalin- ingrad and Gdansk. W est of Kaliningrad, v essels entering and leaving Gdansk harbor show position relocations among sev eral discrete targets rather than a single point. At this figure scale the structure is not fully visible; higher-resolution views indicate circular target patterns. Similar circular structures are observed in other re- gions, including the Black Sea, and are discussed in Section III-F. These observations suggest a structured Fig. 5. FPSE events around Kaliningrad and Klaipeda recorded on 9-11 January 2026. spoofing setup rather than a single simplistic trajectory pattern [7]. As v essels progress farther north and east, additional jumps appear near Klaipeda. The vessels affected near Klaipeda are generally dif ferent from those af fected in the Kaliningrad area. V essels farther offshore near Bornholm and northeast of Estonia also relocate to these same target clusters around Kaliningrad and Klaipeda. Fig. 6 sho ws FPSEs around St. Petersb ur g for the same interv al (9–11 January 2026). Several vessels entering or leaving the gulf near Kronstadt exhibit abrupt reloca- tions, typically about 50 km north or south; some relo- cations are smaller (about 10 km) and remain offshore. For this area, the software also generates a heatmap of all reported vessel positions (not only FPSE-associated tracks) from [11]. A notable feature is the absence of reported positions in the corridor between the St. Pe- tersbur g harbor area and the westernmost FPSE cluster ov er the full three-day interval. In the av ailable data, the af fected region appears to be approximately 25 km by 50 km ( ∼ 1250 km 2 ). Ho we ver , an alternati ve e xplanation is that vessels in this area hav e limited connectivity to the AIS service. T o examine this in greater detail, a heatmap w as gener - ated for the entire Baltic Sea, shown in Fig. 7. The data were recorded on 17–26 December 2025. During this period, only a limited number of FPSEs were detected in the vicinity of Kaliningrad. From the heatmap in Fig. 7, vessel trajectories appear to become sparser just west of Estonia. Similar patterns can be identified to the south-east of Bornholm, as well as a few hundred kilometers north of Gdansk. Based on these observations, it is difficult to draw a firm conclusion regarding the size of a potential spoofing Fig. 6. FPSE events around St. Petersburg, Russia, recorded on 9-11 January 2026. Fig. 7. Heatmap of all reported ship locations in the Baltic Sea, recorded on 17-26 December 2025. area, since the missing positions may result either from AIS communication-range limitations or from deliberate interference effects. Accordingly , the present AIS-only evidence does not allo w a definitiv e separation between spoofing and link- av ailability effects in this region. Nev ertheless, if the operational objective is area-wide disruption of GNSS- dependent maritime services, spoofing remains a plausi- ble mechanism from an adversarial perspectiv e: for large footprints, comparable disruption by jamming would generally require substantially higher transmit po wer . B. The Black Sea Fig. 8 and Fig. 9 present results in the Black Sea for 21–23 January 2026. For clarity , Fig. 8 shows FPSEs only . T wo main acti vity areas are visible: Nov orossiysk and Sev astopol. In Fig. 9, vessel tracks are included. T racks that appear consistent with nominal navigation are mainly visible Fig. 8. FPSEs in the Black Sea, recorded on 21-23 January 2026. Only the FPSEs are included. in the Bosporus and approximately 300 km east of it. Despite the three-day observation interval, the true locations of vessels relocated to Nov orossiysk remain unclear . Fig. 9. FPSEs in the Black Sea, recorded on 21-23 January 2026. FPSEs and ship paths included. In this case as well, the affected area appears large. Similar to Kaliningrad, positions relocate among se veral target clusters, with circular patterns visible within clusters. Fig. 10 provides a zoomed view around Nov orossiysk where these circles are visible. C. Murmansk FPSEs are also routinely observed near Murmansk in the Barents Sea. Examples are shown in Fig. 11 and Fig. 12. The behavior is similar to previous cases in that positions relocate among sev eral target clusters, but circular sub-patterns are less evident. D. Harbor of Haifa, Israel Fig. 13 and Fig. 14 show FPSEs in the eastern Mediterranean off the coast of Israel. In this case, Fig. 10. FPSEs around Nov orossiysk at the Black Sea, recorded on 21-23 January 2026. FPSEs only . Fig. 11. FPSEs around Murmansk at the Barents Sea, recorded on 9-11 January 2026. FPSEs only . anomalous beha vior is concentrated in the harbor of Haifa. Outside the harbor area, many tracks return to nominal behavior . Detected relocations frequently con- ver ge to ward a static target near Queen Alia International Airport in Jordan. V essels traveling from Cyprus to Israel often show Fig. 12. FPSEs around Murmansk at the Barents Sea, recorded on 9-11 January 2026. FPSEs only . sparse or missing reports during the Lev antine Sea crossing. Possible causes include reporting suppression, limited reception by AIS stations, or RF interference. E. Moscow , Russia In the interval 26–27 December 2025, processing identified a rare FPSE episode in Moscow . Fig. 15 shows a pattern similar to Kaliningrad and Nov orossiysk, with relocations onto circular tracks. The true vessel trajectories are difficult to infer; how- e ver , the zoomed vie w in Fig. 16 suggests that affected vessels are likely operating on the Mosco w Ri ver . It is interesting to note that spoofing activity in Mosco w can potentially be detected by monitoring ships position records reported through AIS. F . Discussion of Cir cular T rajectory P atterns As noted in sev eral regions, many target patterns exhibit circular trajectories. Fig. 17 and Fig. 18 provide representati ve examples. The Moscow episode (Fig. 16) Fig. 13. FPSEs around the harbor of Haifa, Israel, recorded on 18-20 January 2026. Showing FPSEs and ship paths Fig. 14. FPSEs around the harbor of Haifa, Israel, recorded on 18-20 January 2026. FPSEs only . appears to show similar behavior . In these examples, the follo wing characteristics are observ ed: • The circles are regular and smooth. • The same circle is occupied by multiple ships. • V essels transition between multiple circles. • Certain arc se gments exhibit denser position con- centrations, sometimes approximating a short tan- gential line segment. If these observations are compared with circular tra- jectories in Fig. 19 and Fig. 20, the following differences are observed: Fig. 15. FPSEs in Moscow , recorded on 26-27 December 2025. Fig. 16. FPSEs in Moscow , recorded on 26-27 December 2025. • The circles are irregular and less geometrically consistent. • Individual circles are typically occupied by a single Fig. 17. FPSEs in circles in Kaliningrad, recorded on 18-20 January 2026. Fig. 18. FPSEs in circles in Novorossiysk at the Black Sea, recorded on 26-27 December 2025. vessel. • In the Haifa harbor case, some relocations are from circular tracks to ward a static tar get near Queen Alia International Airport. • As abov e, certain arc segments show higher point density and occasional short tangential alignments. For the Haifa harbor examples, these circular patterns are interpreted as likely v essel-operational behavior (e.g., maneuvering or fishing) rather than spoofing artifacts. This raises the possibility that some spoofing target patterns may be designed to resemble common maritime motion profiles. Fig. 19. Heatmap and ship paths in the Mediterranean near Haifa harbor showing “imperfect” circle patterns, recorded on 21-23 Jan- uary 2026. G. Amster dam, the Netherlands The challenge of spoofing detection from large po- sition streams is clearly illustrated by Amsterdam-area data. As shown in Fig. 21, a large number of FPSEs are detected in a pattern that appears to recur daily . Some vessels show occasional relocations to distant regions (including locations in Africa and far southward), and these ev ents pass both Stage 1 and Stage 2 criteria. For many vessels, these anomalies are sparse and hav e limited impact on the overall trajectory . Another recurrent artifact is the “back-to-port” jump, where a vessel position abruptly returns to its departure port. An example is shown in Fig. 23. This specific ev ent is remo ved by Stage 2 because it occurs for only one vessel. If the same artifact affects multiple vessels from a common area, it can pass Stage 2 and produce false FPSEs. This mechanism appears to contribute to Amsterdam-area detections. These cases illustrate that the analysis is not fully robust to all data-quality ef fects. Ne vertheless, in its current form the framew ork remains useful for identi- fying candidate spoofing ev ents, particularly when post- processed outputs are revie wed manually . Fig. 20. Heatmap and ship paths in the Mediterranean near Haifa harbor showing “imperfect” circle patterns, recorded on 18-20 Jan- uary 2026. Fig. 21. FPSEs detected in Amsterdam, the Netherlands, recorded on 21-23 January 2026. No ship paths are shown. I V . C O N C L U S I O N S Detection of potential spoofing events from AIS data appears feasible. The quality of the AIS data link and the ov erall AIS cov erage are critical to successful spoofing Fig. 22. FPSEs detected in Amsterdam, the Netherlands, recorded on 21-23 January 2026. Fig. 23. “Back-to-Port” jumps detected in Fort Lauderdale, Florida in the USA, recorded on 15 December 2025. detection, particularly for estimating the extent of the af fected area. The presented analysis was implemented using the SeaSpoofFinder tool, which supports AIS data ingestion, heuristic event detection, and visualization of candidate e vents for expert re view . It is publicly accessible under seaspoof finder .gitub.io/ais data , and is expected to be maintained at least until June 2026. The analysis identifies repeated FPSE patterns in Mur- mansk, Moscow , the Baltic Sea, the Black Sea, and the harbor of Haifa. The observations are consistent with at least three spoofing strategies: • Relocation to multiple circular targets, with transi- tions between circles; observed in Moscow , Kalin- ingrad, and the Black Sea. • Relocation to multiple static targets, with transitions between targets; observed near Murmansk. • Relocation of a smaller operational area to a single static target; observed in the harbor of Haifa. The data suggests that, in some scenarios (e.g., St. Pe- tersbur g), the objectiv e may not be credible displacement of user perception but rather denial of service. Finally , this study is based on detection of implau- sible AIS position beha vior only; therefore, the conclu- sions should be interpreted as e vidence-based hypotheses rather than definitiv e attribution. V . D I S C L A I M E R The results from this article are based on publicly av ailable information. The vie ws set out in this article are those of the authors and do not necessarily reflect the official position of an y organization. R E F E R E N C E S [1] J. A. V olpe, “V ulnerability assessment of the transportation in- frastructure relying on the global positioning system, ” National T ransportation Systems Center, T ech. Rep., 2001. [2] L. Scott, “Anti-Spoofing & Authenticated Signal Architectures for Civil Navigation Systems, ” in Pr oceedings of the 16th International T echnical Meeting of the Satellite Division of The Institute of Navigation (ION GPS/GNSS 2003) , Portland, OR, 9 2003, pp. 1543–1552. [3] OPSGR OUP, “GPS Spoofing Final Report, ” September 2024, comprehensiv e analysis of GNSS spoofing in aviation. [Online]. A vailable: https://ops.group/blog/gps- spoofing- final- report/ [4] GPSW ise, “GPSWise, ” https://gpswise.aero/ , accessed: 2026- 02-16. [5] GPSJam, “GPSJam, ” https://gpsjam.org/ , accessed: 2026-02-16. [6] Stanford University , “Stanford GPS Laboratory – RFI Monitor - ing and Reports, ” https://rfi.stanford.edu/ , accessed: 2026-02-16. [7] GPSP A TR ON and Gdynia Maritime University , “GNSS Inter- ference Monitoring in the Baltic Sea: Shipborne Observ ations near the Kaliningrad Enclave Marine Border, ” Gdynia Maritime Univ ersity , T ech. Rep., 2025. [8] Royal Institute of Navigation, “Impacts of GNSS Interference on Maritime Safety, ” Royal Institute of Navigation, T ech. Rep., Jan. 2026. [Online]. A vailable: https://rin.org.uk/page/ RIN Maritime Report [9] GPSPatron, “GPSP atron, ” https://gpspatron.com/ , accessed: 2026-02-16. [10] International T elecommunication Union – Radiocommunication Sector (ITU-R), “T echnical characteristics for an automatic identification system using time-di vision multiple access in the VHF maritime mobile band, ” International T elecommunication Union, Recommendation ITU-R M.1371-5, Feb . 2014, feb . 2014. [11] AISStream, “AISStream, ” https://aisstream.io , accessed: 2026- 02-16. [12] SeaSpoofFinder, “SeaSpoofFinder AIS Data, ” https: //seaspooffinder .github .io/ais data , accessed: 2026-02-16.