Design a relational database (Access) that identifies breaches in records based on user defined limits
Initial observations are that Index Type and Index Composition are attributes of Index, not of Acceptable_indices. There will be relationships between a security and an index; whether this is important to your use case or not can't be determined from the current information. Concentration should relate to another entity type saying what it is a concentration of.

More generally you need to distinguish what is an acceptable set of values from what was actually in the transaction executed. The acceptable set is your risk and exposure policies documented in the form of a normalised data model. You have to think carefully of all the conditions, including the obscure, infrequent and exceptional ones. For each executed transaction the model must capture sufficient information to determine if it meets the risk policies or not.

There must be a link between an individual transaction and the set of rules that apply to it. The easiest way is to set the rules by security type e.g. one set for bonds, one for equities, one for futures, one for options etc.

Another complication is the time-dependent nature of the data. I'm guessing this application will be for analysis after the transactions are complete, rather than pre-transaction authorisation. Likely there will be a number of days between transaction and analysis. So you need to know what rules were in place when the transaction occurred. Everything must have start and end dates (or datetime values, depending if things can change intra-day).

For a physical database design you could implement one table per entity type. This is the usual way in the absence of a strong incentive to do otherwise. Queries may be longer from this approach (if there are many limiting factors the query will have to bring in the table with limit's allowable values and the table including the actual executed value for each factor). Queries are very obvious, however, and easy to implement and maintain. The runtime engine should have not problem executing them.

Alternatively each limit could be considered as a feature of the deal. The tables reduce to bags of feature values. To check if an executed trade breaks a limit one compare the "allowed" bag of values to the "executed" bag of values. This would be a variation on the Entity Attribute Value (EAV) design pattern. Often this pattern is considered dangerous. Queries are obscure as everything is a "bag" or a "feature"; it is never obvious what each particular feature represents. Writing queries to ensure the limit's feature is compared to the corresponding feature on the trade can be painstaking work. Maintenance even more so. Performance tends to be worse because this is adding an extra layer of abstraction on top of how the engine expects to work. It is wonderfully flexible, however. If you get things just right adding another feature can reduce to a simple cut-and-paste.

A third option would be to hold each value as an attribute. This make the tables very wide. The DBMS will be able to cope with this (up to a limit!) but makes things difficult to read. The real problem comes when there can be multiple acceptable values. For your example there may be two acceptable indexes in the limits and two indexes involved in the trade. You created columns index1 and index2 on each of Limit and Trade table. To check validity one must compare all possible combinations i.e.

(
    limit.index1 = trade.index1
and limit.index2 = trade.index2
)
or
(
    limit.index2 = trade.index1
and limit.index1 = trade.index2
)


This becomes ugly real quick.

My suggestion is to implement it one table per entity. Write the queries and test them. They can be written incrementally, checking first for, say, country validity, then country and index, then country, index and counterparty and so on. If this approach surfaces a particular problem, pause and re-evaluate in the light of the new circumstances.