1) This doesn't appear to be security related. In the future, this sort of question would be much more appropriate in the SQL & PL/SQL forum. Hopefully, a moderator will move it to the proper forum shortly.
2) Why did you create a bitmap index rather than a b*-tree index?
3) How many rows are in the table? How selective are the various individual conditions?
How selective are each of the various conditions? How did you choose the order of columns in your composite index? Was it based on the selectivity of the various conditions?
What is the query plan?
Note that an index need not be unique. You can create a composite index on (id, typ_balance) or (id, typ_balance, status) or (id, typ_balance, typ_portfolio) without requiring that any of those is unique. Whether Oracle is likely to actually use such an index will depend on how selective the various conditions are which is why I've asked that in both of my replies.
You may be unable to do much better than that, 150,000 records is a significant amount of data. Even if you have a perfect index, it would take a few hundred thousand I/Os to complete the query. A disk read typically takes a few milliseconds so the cache hit ratio must be very good for this query in order for you to be able to do better than you do now. And this is not something you can easily control (caching depends on your buffer cache size as well as on how "hot" these data are and how much workload the buffer cache has at that given moment).