First of all, let's take a closer look at FilterSecurityInterceptor. The following figure shows the relationship between FilterSecurityInterceptor and its dependencies:

As you can see, FilterSecurityInterceptor extends AbstractSecurityInterceptor, which holds a reference to an instance of AccessDecisionManager. There are three implementations of AccessDecisionManager: AffirmativeBased, ConsensusBased, and UnanimousBased. These decision managers holds a list of AccessDecisionVoter and there are two implementations of AccessDecisionVoter: RoleVoter and AuthenticatedVoter. The RoleVoter implementation checks whether the granted authorities of the Authentication instance contain the role required to access the request. If the role is granted, then RoleVoter gives an affirmative vote, otherwise, it gives a negative vote. AuthenticatedVoter simply checks whether the authentication inside SecurityContext is authenticated or not and gives an affirmative vote or a negative vote respectively. 

So, AccessDecisionManager make the decision based on the votes from the voters they have. AffirmativeBased will grant access if any AccessDecisionVoter returns an affirmative response, and ConsensusBased will grant access when the affirmative votes are greater than the negative votes. UnanimousBased requires no negative votes to grant access. When access is granted, nothing will help and the request will move forward to Controller. Otherwise, AccessDeniedException will be thrown, and the flow of the control will go back to ExceptionTranslationFilter.