Depending on how you're using the peering exchange, you've got a few different options:
Firstly I'll cover RPKI and say that whilst it's something you should definitely go ahead and deploy, both for your own routes and validating others, it's unfortunately in such low use that you cannot at this point expect it to do all that much. The real solution here is WHOIS - Merit's RaDB is arguably the best since it'll allow you to return results for all RIRs at once. But, if you prefer to query each RIR directly, go for it.
Now, if you're on the exchange and you're just getting a pile of prefixes from the IXP's route server, depending on the tools you've got available to you and the capabilities of your router, you have two possibilities:
1. Filter by origin AS
Essentially, this consists of validating the origin AS of a prefix against the one in WHOIS - if the origin AS isn't matching the one in WHOIS, you drop the prefix and any more-specifics that might also be announced. This is generally a good protection against unintentional hijacks. The vast majority of prefixes should have this data.
2. Filter by transit AS
This takes it a step further and filters routes with any AS in the path that isn't authorised within WHOIS - you can't do this for every prefix however, since not everybody will have created objects specifying who their authorised transit AS providers are.
On the other hand, if you're using the peering exchange to directly peer with others, then your life gets a whole lot simpler; you can lookup what prefixes they have in WHOIS and permit those. Good practice in my opinion is to permit peers to announce more-specifics up to a max length of /24 whilst also setting a sensible maximum-prefix value (i.e. proportional to the number of subnets they have) on your peering so that they can't flood you with routes but can respond to a prefix hijack.
If you're looking for tools, check out IRRToolSet and IRR PowerTools