in the pickup, on overlap, you can cast the OtherActor into your custom Pawn type, then you can access its variables.
or a more versatile method, would be to make a Blueprint Interface, with functions for item collection, then make your pawn implement that interface, and have the pickup call that interface function on the OtherActor, without casting. the reason this method is better, is because you may want many different actors to be able to pick things up, and it would be innefficient to cast to many different classes that may want to pick things up.
also, you generally shouldn’t have an actor directly checking or setting the variables owned by another actor, that breaks encapsulation and can lead to debugging/security/maintenance/design problems. actors should only call functions in the other actor, and let the other actor decide whether to set or get its own variables. each actor should be the only class that edits its own variables, and other actors should have to ask this actor with a function, if they want to edit or read its variables. there are some exceptions to this, but its generally good to avoid breaking encapsulation, by using getter or setter functions.
for example, lets say you had pickup items that directly changed a boolean in your character.
if you decide that you want to redesign those booleans in your character into an integer or an Enum or an array of Names, then it would break that pickup actor. so everytime you changed the implementation of collecting items, you would need to edit the Character and the Pickup, and TreasureChests, and NPCs and any event in the game that used that item system would need to be fixed…
instead, if those pickups, treasureChests, and NPCs all called a function on the character to give an item, you could change how that function works, and it wont break all the actors that use the function.