You seek to determine the relative timing of two events by the usage of radio.
While one mechanism of doing this would be to synchronize clocks and transfer timestamps, to do that you would first needs a mechanism for synchronizing clocks by radio; and if you had that you could simply use the mechanism directly for the events of interest.
So imagine a transmitter, which at the instant of catching starts a local millisecond counter. It will then encode a series of packets, each containing both an event number, and the amount of time elapsed from the triggering event to a given packet, eg the first packet would be event 1, 10 millisecond delay. And then next perhaps event 1, 60 millisecond delay, then event 1, 110 milliseconds, and so on. Either send enough packets that you are sure that one gets through, or until you receive in response an acknowledgement from the other end of the radio link.
At the receiving end, you will also detect the time of an event, and record that time according to some local relatively rate-accurate clock, but with no need to know any absolute time. When you receive an event report, you record the time at which the packet is received. Then you subtract the since-event delay encoded in the packet, and also a calculated or pre-measured packet duration, and any pre-measured system latencies of significance. If your transmitter will keep sending until it gets an ack, then send it back an ack referencing the appropriate event number. Make a comparison of the calculated remote time to the local time, and declare the winner. The same idea can be used to compare two remote senders, instead of a remote with a local.
Hardware wise, you want a radio that has likely chance of covering the distance, can encode 5-10 bytes of information in a packet of short time duration, and ideally offers bi-directional capability so that you can send an ack back. In practical terms, it will be far easier to develop this with an SPI-connected digital packet radio chip, probably using some variation of FSK modulation. Additionally, to make the individual packet delay stamps work, you'll need direct control of the packet assembly at low level, rather than be handing application messages off to a stack (eg, you need something UDP-like rather than TCP-like).
There are a variety of candidate bands depending on regional regulations, eg 433 MHz, 868, 915, and 2.4 GHz. All of these are supported by a variety of radios, and many of those have some support in the "RadioHead" library which would be a good starting point for trying possibilities. Some particular ideas to consider would be an RFM69, or possibly a 2.4 GHz nRF24, at least in a module with a power amp. To some extent, the overall scheme can be radio agnostic and could be ported to different hardware.
BLE radios as mentioned by Mark Levitt are potentially a possibility, and do have the advantage that a smartphone could be used for scorekeeping. Yet they also present a few challenges. One is that they will have somewhat shorter range than a lower frequency system might. Another and perhaps more serious is that it may be hard to put a unique "time since catch" in each individual packet, as in connected modes the BLE stack would automatically retry something that didn't get through, with the exact same data as before. One might consider something like the vertically open source Apache MyNewt stack on nRF52 hardware rather than typically closed-source vendor BLE stacks. It may be relatively easier to "hack" a stack to use BLE advertisements to emit single unique packets - there is some published work on advertisement based BLE clock synchronization. It could also be possible to use a semi-custom 2.4 GHz scheme to work out the actual timing, and then turn around and use the same radio to send the results to a phone.
Another option that might enter into a conversation would be LoRa chips like the S127x/RFM9x which go for around $10 on a module. The actual LoRa modulation modes of these are generally for yet longer range needs with packets sent at a slower data rate, but something like SF6 at 500 kHz bandwidth is likely useably fast; the chips also support FSK modes comparable to those of an RFM69. Likely going this route simply increases cost with little benefit, though if cost isn't particularly a concern its worth mentioning that the multi-channel LoRa "concentrator" chips used in $100+ LoRaWAN gateways can receive multiple signals at the same time, and tag each packet in hardware with a microsecond timer, which would make comparison quite simple (for simultaneous reception you would be limited to SF7 @ 125 kHz as the fastest mode however). Apart from decreasing conflict between multiple senders (do you need to outfit the whole field team?) it's not obvious that this would be worth the money.
@CFCBazar mentioned NFC earlier, and while that wouldn't work for transferring data across even the infield, it could potentially be used as a sort of "proof of possession" of the ball. However even then, it may take some engineering to make a system which can't be cheated in terms of timing by slapping your glove just before catching and detecting an NFC tag in the ball.
That then raises the idea of putting one of of the timing transmitters in the ball itself. In a way this is cheaper, since you don't need to outfit the whole team, but it's probably fairly tricky engineering in practice, it's not entirely clear the reference crystal will survive the bat, and of course any pretense of being regulation equipment would be a long process of testing and approval away.