This kind of issue is common in distributed systems. The simplest solution is to combine the check for whether a change is allowed with the request to make the change. This technique is useful in a number of contexts. For example, let's forget the loan for a second and just focus on the credit card. Let's say you have a table that contains active credit card applications and you have multiple instances of the service running. You want to prevent someone from having two active applications at the same time (e.g. they refresh the page and submit twice.) In the situation that the services are stateless, each submission could end up on a different instance of the service. Since one service has no idea what the other is doing, we have to look to the database to address this.
One approach is to do an insert or update conditionally. For example, you update the application state to active only if there count of active applications is zero. This is done as a single atomic statement on the DB. Then you check the number of record updated. If that is zero, that update was preempted, if it's something else, that call succeeded. This is kind of like optimistic locking which tends to be less problematic than pessimistic locking. Even if you use a pessimistic lock, the kind of approach I am describing needs to be used to acquire the lock. You might as well skip that extra layer and get to the point.
The situation with two different services is basically the same problem. The question is whether you distinct storage for each and whether they have strong consistency guarantees. In the case that you have separate DB solutions for each service (as would be expect in a microservice architecture) you might want to introduce a third service that acts as an arbitrator for such scenarios. This would allow you to choose storage with strong consistency guarantees as well.
Lastly, you need to balance the cost of this with the likelihood of it occurring. Would having some check after the fact be good enough? If it almost never comes up, contacting the customer to tell them their applications are both denied and they need to choose one might suffice from a business perspective.