I TRADING DESK PSYCHOLOGICAL ANALYSIS ?

Yesterday I have a discussion with one of my friend about managing accounts and manage risk how and what we do ?

• Risk
• Traders
• Management
• Audit
• Decision

IT IS NOT MY FAULT - WHY IT IS SO HARD TO TAKE RESPONSIBILITY

A fundamental truth of trading in a a hedge found or a bank is that one must take full and complete responsibility for both failures and successes. It is easy to take credit for a winning trade, but a losing trade? Our first instinct is to find an excuse: "The market conditions changed too quickly. The market makers are manipulating the price again. I should not have taken the advice offered by that uninformed analyst." It is easy to find excuses for losing trades, but in the end, a winning trader takes full responsibility for all aspects of a trade, what went right and what went wrong. Taking full responsibility is crucial. Traders who do not take full responsibility will devote the bulk of their psychological energy to defending themselves against their mistakes. Rather than cultivating a pristine view of the markets, they will tend to hold a view distorted by their burning desire to avoid blame. In addition, while one is finding an excuse for an adverse event, no time and energy is devoted to anticipating adverse events and thinking of preventative strategies to neutralize them. Unfortunately, for many traders it is difficult to take full and complete responsibility.

Why is it so hard to take full responsibility? A variety of psychological explanations exist, and they differ depending on the person and his or her psychological history. Everyone tends to avoid responsibility to some extent. There is a very human tendency to build up our egos and feel good about ourselves. In explaining the outcomes of our lives, we often attribute success to our skill, intelligence, and talent, and attribute failure to external circumstances, over which we had no control. This general tendency usually helps us cope with most of the adverse events we encounter in our everyday lives, but this tendency is self-serving and impedes one from taking preventative measures to anticipate potential adverse events.

SOLVING THIS ISSUE IS SIMPLE IF WE HAVE THE KNOW HOW !

For some people, making excuses and avoiding responsibility is rooted in early childhood. Some people grew up with parents who spent all their effort pointing out and severely punishing every single mistake their children made. As children, they learned that to avoid punishment, they had to make an excuse and place the blame for the mistake on anyone but themselves. The consequences of making even the most minor mistake were so dreadful that they felt a strong need to avoid responsibility at all costs. Perhaps most people experienced this type of parent-child transaction to some extent, but at an extreme, it can incapacitate. One becomes afraid to act out of a fear of failure. And when a trader fears failure, he or she will be unable to try out new trading ideas or will be afraid to accept full responsibility for the trade.

Risk analysis is often viewed as a “black art”—part fortune telling, part mathematics. Successful architecture risk analysis, however, is nothing more than a business-level decision-support tool: it’s a way of gathering the requisite data to make a good judgment call based on knowledge about vulnerabilities, threats, impacts, and probability.

Established risk-analysis methodologies possess distinct advantages and disadvantages, but almost all of them share some good principles as well as limitations when applied to modern software design. What separates a great software risk assessment from a merely mediocre one is its ability to apply classic risk definitions to software design and then generate accurate mitigation requirements. A high-level approach to iterative risk analysis should be deeply integrated throughout the software development life cycle.1 In case you’re keeping track, Figure 1 shows you where we are in our series of articles about software security’s place in the software development life cycle

As a corpus, “traditional” methodologies are varied and view risk from different perspectives. Examples of basic approaches include financial loss methodologies that seek to provide a loss figure to balance against the cost of implementing various controls; mathematically derived “risk ratings” that equate risk with arbitrary ratings for threat, probability, and impact; and qualitative assessment techniques that base risk assessment on anecdotal or knowledge-driven factors.

Each basic approach has its distinctly different merits, but they almost all share some valuable concepts that should be considered in any risk analysis. We can capture these commonalities in a set of basic definitions:

The asset, or object of the protection efforts, can be a system component, data, or even a complete system.

Risk, the probability that an asset will suffer an event of a given negative impact, is determined from various factors: the ease of executing an attack, the attacker’s motivation and resources, a system’s existing vulnerabilities, and the cost or impact in a particular business context.

The threat, or danger source, is invariably the danger a malicious agent poses and that agent’s motivations (financial gain, prestige, and so on). Threats manifest themselves as direct attacks on system security.

A vulnerability is a defect or weakness in system security procedure, design, implementation, or internal control that an TRADER can compromise ALL !! . It can exist in one or more of the components making up a system, even if those components aren’t necessarily involved with security functionality. A given system’s vulnerability data are usually compiled from a combination of OS- and application-level vulnerability test results, code reviews, and higher-level architectural reviews. Software vulnerabilities come in two basic flavors: flaws (design-level problems) or bugs (implementation-level problems). Automated scanners tend to focus on bugs, since human expertise is required for uncovering flaws.

Countermeasures or safeguards are the management, operational, and technical controls prescribed for an information system that, taken together, adequately protect the system’s confidentiality, integrity, and availability as well as its information. For every risk, a designer can put controls in place that either prevent or (at a minimum) detect the risk when it triggers.

The impact on the organization, were the risk to be realized, can be monetary or tied to reputation, or it might result in the breach of a law, regulation, or contract. Without a quantification of impact, technical vulnerability is hard to handle—especially when it comes to mitigation activities.

Probability is the likelihood that a given event will be triggered. It is often expressed as a percentile, although in most cases, probability calculation is extremely rough.

Although they start with these basic definitions, risk methodologies usually diverge on how to arrive at specific values. Many methods calculate a nominal value for an information asset, for example, and attempt to determine risk as a function of loss and event probability. Others rely on checklists of threats and vulnerabilities to determine a basic risk measurement.. will be continue .........